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

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.