[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.