[TrimmableTypeMap] Pre-generating code for Mono.Android and other SDK assemblies

Part of https://github.com/dotnet/android/issues/10788

The implementation of the typemap lookup data structure in .NET 10 in CoreCLR scans assembly-level attributes in the type map assembly and builds a `Dictionary`. This can be noticeably slow for large typemaps, especially in Debug builds, where there are all the types from Mono.Android (~8000) and from all the other libraries and the app itself. In Native AOT, the lookup data structure is pre-compiled and ready to use at runtime without costly initialization. The Runtime team is looking into pre-compiling the same intrinsic data structure through crossgen2 (R2R).

We could save the developers a few seconds during each Debug build and several hundreds of millisecodns every Debug build startup if we split the typemap in two: one pre-generated in the Mono.Android during SDK build time that could be pre-compiled through crossgen2 once we implement https://github.com/dotnet/android/issues/10760. During prototyping, assembly scanning and IL + Java codegen took roughly 6s on MacBook M1 of which 5s was spent just scanning Mono.Android. The build time gain would be even more pronounced on lower end dev machines.

**Goal:** There is no need to do assembly scanning for the huge Mono.Android.dll and there's optimization opportunity
Mono.Android is scanned and code for its typemap is generated into a `Mono.Android.TrimmableTypeMap.dll` (with its own internal "type mapping universe" type) + the java code for JCWs is precompiled in `mono-android-trimmable-typemap-jcw.jar`.

Runtime code will need to be adjusted to use the Mono.Android and app-specific typemaps together