Add trim-aware runtime EventSource foundation - #12843

## Summary

Layer 2 of registered GitHub stack `12855`, built on the EventSource foundation merged by #12843.

- emit the reserved `Microsoft.Android.Runtime` GC bridge events (IDs 7/8, keyword `0x8`, task 1)
- measure the complete logical bridge round: Start after callback validation and before `EnsureAllContextsAreOurs`; Stop after collected-context processing, `JavaMarshal.FinishCrossReferenceProcessing`, and `AndroidRuntimeInternal.NotifyBridgeProcessingFinished`
- evaluate EventSource enablement once at Start, latch it on the dedicated serialized bridge thread, and use that decision at Stop
- initialize the enabled provider during bridge setup so the first event does not lazily construct EventSource while a GC is waiting
- preserve feature-off trimming of provider initialization and both production call sites
- document the boundary and zero-payload contract

This intentionally does not add typemap lookup instrumentation, modify `TimingLogger`, or remove/disable `FastTiming`.

## Validation

- `Mono.Android.Runtime.csproj` build
- `Mono.Android.csproj` build
- full Debug local SDK build
- `RuntimeEventSourceFeatureSwitch` linker tests: 2 passed
- CoreCLR Mono.Android.NET GC bridge/provider tests with `AndroidTypeMapImplementation=llvm-ir`: 3 passed, 1 pre-existing ignored
- CoreCLR Mono.Android.NET GC bridge/provider tests with `AndroidTypeMapImplementation=trimmable`: 3 passed, 1 pre-existing ignored

## Stack

- Foundation: #12843, merged into `main`
- Base: `main`
- This layer: #12849
- Next layer: #12851
- Registered GitHub stack: `12855`

Co-authored-by: Copilot App <[email protected]>

## Summary

Layer 3 of registered GitHub stack `12855`, above #12849 and foundation #12843.

- own the complete trimmable typemap provider contract: event IDs 9/10, keyword `0x4`, task 2, and `JavaToManaged` / `ManagedToJava` direction payloads
- instrument trimmable typemap cache-population misses in both directions
- check `RuntimeFeature.EventSourceSupport` and listener/keyword enablement only inside the `ConcurrentDictionary.GetOrAdd` miss factories
- latch Start emission and pair Stop in `finally`, including failed and throwing backend lookups
- preserve linker removal when `EventSourceSupport=false`
- document exact miss-only semantics and payloads

Cache hits perform no feature-switch or EventSource enablement check and emit no events. The Stop payload has no success/found field, matching the provider contract.

This layer remains scoped to the trimmable typemap path on the current CoreCLR-only runtime model. It does not add legacy runtime assumptions and does not modify TimingLogger or FastTiming.

## Validation

- `./dotnet-local.sh build src/Mono.Android/Mono.Android.csproj -v:minimal`
- `./dotnet-local.sh test bin/TestDebug/net10.0/Xamarin.Android.Build.Tests.dll --filter "Name~RuntimeEventSourceFeatureSwitch"` — 2 passed
- trimmable CoreCLR on-device `Mono.Android.NET-Tests`, categories `TypeMap,GCBridge` — 7 passed, 1 expected skip
- default CoreCLR on-device `Mono.Android.NET-Tests`, category `TypeMap` — 4 expected trimmable-only skips; no default-path timing assertion remains

## Stack

- Base: #12849 / `simonrozsival-gc-bridge-timing`
- This layer: #12851
- Next layer: #12853
- Registered GitHub stack: `12855`

## Summary

- mark `Android.Runtime.TimingLogger` obsolete with guidance to use `Stopwatch` or `EventSource`
- replace its native FastTiming-backed implementation with managed monotonic timing while preserving the `Logger.LogTiming` opt-in gate, `monodroid-timing` logcat tag, default message, elapsed format, and idempotent state transitions
- remove the remaining `monodroid_timing_start`/`monodroid_timing_stop` declarations, CoreCLR dispatch entries, NativeAOT stubs, and native managed-timing sequence allocator

## Stack

Layer 4 of registered GitHub stack `12855`, above #12851, #12849, and #12843.

- Base: `main` (the lower layers have merged)
- This layer: #12853
- Top layer: #12854

FastTiming instrumentation, timing properties/modes, dump handling, call sites, and FastTiming tests are intentionally retained here and deferred to Layer 5.

## Validation

- `Mono.Android.csproj` build with API compatibility checks
- `native-clr.csproj` x86_64 build
- `native-nativeaot.csproj` x86_64 build

The APK descriptions now use the versions from `main`. The Mono runtime and its generated P/Invoke table were removed upstream, so no Mono-specific validation remains in this layer.

## Summary

Layer 5 and the top PR of registered GitHub stack `12855`, above merged #12853, #12851, #12849, and #12843.

- remove native FastTiming instrumentation, event storage, formatting, summaries, configuration, and self-overhead measurement
- remove the shared FastTiming implementation/static library and all CoreCLR timing call sites
- remove FastTiming properties/modes, JNI/export dump entrypoint, broadcast receiver, manifest overlay, packaging hooks, and `_AndroidFastTiming`
- retain the exact plain `timing` log category for the obsolete managed `Android.Runtime.TimingLogger`
- remove the obsolete `FastTimingTests` device test
- direct runtime/JIT/loader diagnostics to EventPipe and Android bridge/type-map diagnostics to `Microsoft.Android.Runtime`
- refresh CoreCLR APK size references from a local rebuild after rebasing onto current `main`

## Size

The four `BuildReleaseArm64` CoreCLR references were regenerated locally after rebasing onto `main` (`64920590083e2d50e0d99d716ce2d82c46bdb4f9`):

| Variant | APK delta | `libmonodroid.so` | Delta | Assembly-store delta |
|---|---:|---:|---:|---:|
| Simple CoreCLR | -12,288 B | 158,792 → 120,096 B | -38,696 B (-24.37%) | +512 B |
| Simple CoreCLR + R8 | -16,384 B | 158,792 → 120,096 B | -38,696 B (-24.37%) | +664 B |
| XForms CoreCLR | -12,288 B | 151,488 → 120,096 B | -31,392 B (-20.72%) | -192 B |
| XForms CoreCLR + R8 | -12,288 B | 151,488 → 120,096 B | -31,392 B (-20.72%) | -200 B |

The size matrix passed all four `BuildReleaseArm64` regression tests after copying the freshly generated `.apkdesc` files.

The earlier managed-size investigation used isolated merge-base/PR builds and extracted every assembly. It found no managed DLL size growth: all extracted assemblies had identical uncompressed totals before and after this PR. The small assembly-store changes above are compressed/layout differences, not a ~100 KiB managed-code increase.

## Startup

Prior balanced startup measurements showed overlapping distributions and no measurable startup effect; no startup regression or improvement is claimed.

## Validation

- rebased onto current `main` and resolved `host.cc` plus four APK reference conflicts
- full `make all CONFIGURATION=Release`
- CoreCLR APK size regression tests: 4 passed
- CoreCLR EventSource linker feature-switch tests: 2 passed
- CoreCLR `RunWithLogging` property regression test verifies `debug.dotnet.log=default,assembly,timing`
- trimmable type-map tests: 1,277 passed, 1 skipped
- native no-op incrementality: `_ConfigureRuntimes` and `_BuildAndroidRuntimes` skip with no CMake/Ninja execution
- managed `TimingLogger` and lower-layer EventSource/type-map contract sources remain unchanged

## Stack

- Final base: `main`
- This layer: #12854
- Registered GitHub stack: `12855`