[TrimmableTypeMap] Optimize build times

[simonrozsival]

Part of #10788

Track build-time optimization opportunities for the trimmable type map generation pipeline (GenerateTrimmableTypeMap task).

Current performance (PR #10924 benchmarks, MacBook M1)

Phase	Avg	P50	P95
Scan (8870 types)	235ms	224ms	319ms
Emit (typemap assemblies)	86ms	75ms	181ms
JCW (315 Java files)	766ms	409ms	3167ms
Total cold	1088ms	702ms
Total incremental (scan only)	221ms	215ms

Optimization opportunities

• Parallelize JCW source generation — each Java file generation is independent; running them in parallel could significantly reduce the JCW phase which dominates cold build time (suggested by @elinor-fung in [TrimmableTypeMap] Add GenerateTrimmableTypeMap MSBuild task and targets #10924 (comment))
• Parallelize assembly scanning — scanning assemblies for Java peers could be parallelized across assemblies (suggested by @elinor-fung in [TrimmableTypeMap] Add GenerateTrimmableTypeMap MSBuild task and targets #10924 (comment))
• Use MSBuild partial builds — replace the in-task timestamp checking with MSBuild native Inputs/Outputs 1-1 mapping so MSBuild only passes changed assemblies to the task, eliminating the stamp file (suggested by @jonathanpeppers in [TrimmableTypeMap] Add GenerateTrimmableTypeMap MSBuild task and targets #10924 (comment))
• Cache scan results across incremental builds — currently all assemblies are rescanned every build for cross-assembly type resolution; caching the scan index or adding a two-list Scan overload could skip unchanged assemblies
• Skip unchanged JCW files — avoid writing Java files whose content hasn't changed (attempted but read+compare cost negated savings; may be worth revisiting with content hashing)
• XDocument → XmlReader/XmlWriter for manifest generation — the manifest generator uses System.Xml.Linq (full DOM tree); explore streaming with XmlReader/XmlWriter to reduce allocations (suggested by @jonathanpeppers in [TrimmableTypeMap] Assembly-level manifest attribute scanning #11035)

[simonrozsival]

PR #10959 adds per-assembly acw-map.{AssemblyName}.txt files as a side-output of GenerateTrimmableTypeMap. When optimizing incremental builds (e.g., per-assembly Inputs/Outputs or the two-list Scan overload), the acw-map files should be included in the incrementality story:

• If an assembly is unchanged and its scan is skipped, the per-assembly acw-map file should also be preserved (not regenerated)
• AcwMapWriter.WriteToFile already does content comparison to avoid unnecessary timestamp updates, but skipping the write entirely (when the scan is skipped) would be even better
• The _MergeAcwMaps target uses Inputs/Outputs on the per-assembly files, so it will automatically skip if no acw-map file was touched

Adding this as a consideration item for the incremental build optimization work.

[simonrozsival]

Additional optimization: XDocument → XmlReader/XmlWriter for manifest generation

The manifest generator currently uses System.Xml.Linq (XDocument/XElement) which builds a full DOM tree in memory. For forward-only XML operations (e.g., reading the template manifest, writing the final output), XmlReader/XmlWriter would be more efficient — streaming and allocation-free.

Challenge: The current manifest generation requires read-modify-write semantics (load template → query existing elements for dedup → add new elements → save). This inherently needs a DOM. A pure XmlReader/XmlWriter approach would require building a custom in-memory model or restructuring the merge logic into a single streaming pass.

Potential approach:

• Read template with XmlReader, build a lightweight custom model (just element names + attributes for dedup)
• Generate new elements directly
• Write everything with XmlWriter in a single pass

Raised by @jonathanpeppers in #11035 (review)

[simonrozsival]

Follow-up from PR #11037: we prototyped broader incremental invalidation for _GenerateTrimmableTypeMap by hashing manifest-affecting MSBuild properties into an inputs cache file, but we are deferring that change to this issue to keep the manifest-rooting PR focused. If we pick this up here later, commit e9d0850 has a starting point for the approach.