[TrimmableTypeMap] Split Debug typemap generation into per-assembly MSBuild units

[simonrozsival]

Part of #10958.

This tracks the main Debug inner-loop optimization: split monolithic trimmable typemap generation into per-assembly MSBuild units so changing one app/library assembly does not require regenerating every typemap DLL.

This should likely build on the dependency pre-task and separate entry-point task tracked by sibling sub-issues.

Current state

• _GenerateTrimmableTypeMap invokes one GenerateTrimmableTypeMap task with all reference/app/framework assemblies.
• JavaPeerScanner eagerly indexes all assemblies in the task invocation.
• The generator emits per-assembly typemap DLLs, but they are produced within one monolithic task execution.

Proposed Debug flow

• Invoke a GenerateTypeMapUnit-style task per input assembly or per dependency unit.
• Pass the unit's input assembly and its reference/dependency closure.
• Use MSBuild Inputs/Outputs per unit so unchanged units are skipped by MSBuild, not by in-task timestamp heuristics.
• Generate the root _Microsoft.Android.TypeMaps.dll in a downstream task from the generated per-unit typemap DLL list.
• Keep Release behavior monolithic/shared-universe at first unless the implementation can safely preserve Release alias-merging semantics.

Acceptance criteria

• In Debug, changing one app/library assembly only reruns the typemap unit(s) affected by that assembly and its relevant dependency closure.
• Release/shared-universe behavior remains correct.
• Generated typemap/JCW/manifest/runtime behavior remains compatible with existing tests.
• Add incremental build tests proving unaffected typemap DLLs are not regenerated.

[simonrozsival]

While resolving stale Java-source cleanup in #11604, we discussed one area that needs special attention when this issue moves from whole-world generation to per-assembly incremental generation.

Short-term in #11604, the generator is still whole-world: when _GenerateTrimmableTypeMap runs, it scans the current full assembly set and returns the full desired Java source list. That makes it safe to reconcile by diffing:

• current generated Java outputs from the task
• existing $(IntermediateOutputPath)typemap/java/**/*.java

and deleting files that are not in the current generated set, plus the corresponding copied files under $(IntermediateOutputPath)android/src/.... No-op incremental builds where _GenerateTrimmableTypeMap is skipped do not clean this directory.

For the per-assembly split tracked here, that simple full-directory diff becomes risky unless we design ownership explicitly. Java output is trickier than typemap DLL output because a generated Java file is not always isolated to the assembly that changed:

• manifest rooting can change which peers need Java output;
• deferred-registration propagation walks up/down type hierarchies and can affect peers from other assemblies;
• cross-assembly alias ownership can move peers between assembly groups;
• Java/JNI path casing is significant, so stale cleanup must not use case-insensitive identity for generated Java names;
• _GenerateJavaStubs copies from typemap/java to android/src, so stale cleanup must account for both the source file and the copied Java file;
• removed/renamed assemblies, changed package naming policy, or changed ownership buckets can leave old directories/files behind;
• cleaning an assembly bucket before a per-assembly unit runs could race with or delete outputs owned by other units if the ownership model is not exact.

Before making Java generation partial, we probably need one of these explicit models:

1. each typemap unit emits an output manifest listing exactly the Java files it owns, with a merge/reconcile target that deletes only files no longer owned by any current unit; or
2. each unit writes to an isolated staging directory and a downstream target publishes/merges the complete current Java set into typemap/java and android/src.

Acceptance criteria worth adding here:

• no-op incremental builds preserve valid generated Java files;
• changing one assembly does not delete unaffected Java files;
• removing a type or assembly deletes both stale typemap/java and stale android/src copies;
• case-only Java/JNI path changes behave correctly on case-sensitive filesystems;
• manifest/deferred-registration changes that affect peers outside the changed assembly are covered;
• stale output directories from removed/renamed units do not accumulate.