IL: add ILPreNamespace, make ILPreTypeDef creation lazy

[auduchinok]

This PR groups lazy type definitions into lazy namespaces structure, allowing to make nested namespaces lazy and defer lazy type defs creation. It improves the custom module readers that we have in Rider.

In addition to that, the PR adds tests asserting the type defs are not eagerly read, which discovered several issues. This PR, #20088, and #20090 all fix these issues. The constraint fix has the most effect for the most users, since without it the type defs were effectively not lazy at all.

The following was measured with the other two PRs included.

Retained memory after ParseAndCheckProject (retain-project, avg of 3):

Project	main 8c0e444de	branch + other PRs	vs main
Console — 168 refs / 3 src	77.7 MB	59.9 MB	−17.8 (−22.9 %)
FSharp.Common — 486 refs / 58 src	1319.2 MB	766.0 MB	−553.2 (−41.9 %)
FCS — 124 refs / 397 src	2308.7 MB	2289.2 MB	noise

Type defs actually read out of the references:

Project	top-level TypeDef rows	read before constraint fix	after	namespace levels realised
Console — 168 refs	3 905	3 905 / 3 905 (100 %)	2 280 / 3 905 (58 %)	428 → 300
FSharp.Common — 486 refs	106 980	107 356 (≈100 %) †	34 877 / 106 980 (33 %)	11 262 → 3 964
FCS — 124 refs	not instrumented	—	—	—

† Denominator is top-level rows only while the read counter also fires for nested type defs.

ParseAndCheckProject — warm (1 warm-up, then samples with the IL reader cache cleared each time):

Project	main: time (min / median)	branch: time (min / median)	main: allocated	branch: allocated
Console — 168 refs / 3 src	109 / 122 ms	95 / 110 ms (−13 % / −10 %)	110.2 MB	96.4 MB (−12.5 %)
FSharp.Common — 486 refs / 58 src	1832 / 2027 ms	1699 / 1968 ms (−7 % / −3 %)	3167 MB	2670 MB (−15.7 %)
FCS — 124 refs / 397 src	3060 ms (min)	2906 ms (min)	14 347 MB	14 340 MB (−0 %)

[github-actions]

🔍 Tooling Safety Check — Affects-Compiler-Output
Affects-Compiler-Output: modifies IL reader (il.fs, ilread.fs), import, and static linking

Generated by PR Tooling Safety Check · opus46 3M · ◷

[auduchinok]

This is ready.

[T-Gro]

🤖 This review was generated by AI (@expert-reviewer agent). Findings may contain inaccuracies — please verify independently.

Reviewed the lazy-namespace refactoring end to end (il.fs/il.fsi, ilread.fs, import.fs, illib.fs, and the order-sensitive consumers). No correctness defects found — the change is well engineered and the tradeoffs are documented in-line. Notes on what I checked:

• Concurrency: DelayInitValue and ILTypeDefs.RealiseNamespaces are correct double-checked locking (volatile stores, non-cached exceptions). They lock this while DelayInitArrayMap locks a private syncObj, so the two paths don't interfere.
• Enumeration order: AllPreTypeDefs regroups by namespace only for tables built via mkILTypeDefsGroupedComputed (the metadata reader). Flat tables (mkILTypeDefsFromArray, as used by FSI/ilreflect for generated modules) have no child pre-namespaces, so GetArray() order is preserved. The one read-order-sensitive consumer, StaticLinking, now sorts by MetadataIndex. ✓
• ImportILAssemblyExportedType: moving FindByName inside the try that maps KeyNotFoundException to the friendly impReferenceToDllRequiredByAssembly error is a slight improvement over the old path (which let KeyNotFoundException escape), not a regression.
• TypedTree.DemangledModuleOrNamespaceName and NameResolution reorderings are semantically equivalent to the originals while avoiding a forced read.
• noTypars singleton: LazyWithContext.NotLazy [] is an already-forced, never-mutated record, so sharing one instance across all no-typar entities is safe.

One non-blocking readability note inline.

[T-Gro]

Non-blocking: this inner addConstraintSources (line 2347) is a non-rec binding, so this call resolves to the module-level addConstraintSources (line 495) — which is the intent, and correct as written. It's a mild footgun though: reusing the exact same name means a future refactor that adds rec, or that hoists/renames the outer function, would silently turn this into unbounded self-recursion. A distinct name (e.g. addConstraintSourcesIfFSharp) would make the delegation explicit and remove the trap.