[TrimmableTypeMap] Parallelize assembly index construction during Java peer scanning

Part of #10958.

Assembly scanning is still eager and sequential. `JavaPeerScanner.Scan(...)` first calls `AssemblyIndex.Create(...)` for every assembly, then scans every populated index. This issue tracks a safe first step: parallelizing the independent index-building portion and documenting/refactoring any shared-state blockers for later scan parallelism.

## Current locations

- `src/Microsoft.Android.Sdk.TrimmableTypeMap/Scanner/JavaPeerScanner.cs`
- `Scan(...)` builds all `AssemblyIndex` instances serially, stores them in `assemblyCache`, then scans each index.
- `src/Microsoft.Android.Sdk.TrimmableTypeMap/Scanner/AssemblyIndex.cs`
- `AssemblyIndex.Create(...)` builds one assembly index from a `PEReader` and assembly name.

## Suggested implementation

- Start with parallelizing `AssemblyIndex.Create(...)`, since each assembly index is independent.
- Merge results back into `assemblyCache` deterministically after parallel work completes.
- Preserve scan/result ordering where it affects generated output.
- Do not parallelize later phases that mutate shared dictionaries/caches until they are made thread-safe or refactored.

## Acceptance criteria

- Assembly index construction can run in parallel without changing generated typemap/manifest/JCW output.
- Output remains deterministic.
- Add or update tests as needed to cover stable output with multiple input assemblies.