feat: TTID pre-launch capture for cross-platform SDKs support

[marco-saia-datadog]

What does this PR do?

Three things:

1. New AppLaunchPreInitCollector in dd-sdk-android-internal. It's a singleton that collects timing data before the SDK initializes — process start time, first Activity.onCreate, and first frame drawn. State transitions use atomic compare-and-swap (NOT_INSTALLED → IDLE → CAPTURING / CLAIMED → COMPLETE) so the collector and the SDK can't race on who drives startup.

2. New dd-sdk-android-rum-prelaunch module with a single ContentProvider (AppLaunchCollectorProvider) that installs the collector automatically at process start. No customer code required.

3. RumFeature.initRumAppStartupDetector() now checks collector state on init: if data is already captured, read it; if capture is in progress, subscribe; if not installed or the SDK got there first, fall back to the existing RumAppStartupDetector flow unchanged.

RumFirstDrawTimeReporter and WindowCallbacksRegistry are also moved to dd-sdk-android-internal, since both paths need them now. The originals in dd-sdk-android-rum are deleted.

Motivation

React Native and Flutter initialize the Datadog SDK from JS/Dart, well after the first activity has launched. TTID goes unreported for those SDKs unless you add native initialization (DdSdkNativeInitialization.initFromNative()), which means native Android code in a cross-platform project.

The collector sidesteps this. By the time the SDK starts, the timing data is already waiting.

Native Android apps are unaffected. If the SDK initializes before the first activity, it claims the collector and the existing RumAppStartupDetector path runs exactly as before.

Additional notes

• dd-sdk-android-rum-prelaunch is opt-in. Cross-platform SDKs depend on it; native apps don't.
• RumFirstDrawTimeReporterImpl takes an injectable warnLogger lambda. RumFeature passes one that routes through sdkCore.internalLogger with Target.TELEMETRY + Target.USER. The pre-init path defaults to Log.w since there's no SDK available at that point.
• API surfaces updated for both modules. No public API change.

Review checklist (to be filled by reviewers)

• Feature or bugfix MUST have appropriate tests (unit, integration, e2e)
• Make sure you discussed the feature or bugfix with the maintaining team in an Issue
• Make sure each commit and the PR mention the Issue number (cf the CONTRIBUTING doc)