IL: fix the per-reader string cache sizing

[auduchinok]

ILMetadataReader keeps two string tables per referenced assembly. Both were sized from something
unrelated to how many strings are actually read.

cacheStringHeap was sized stringsStreamSize / 50 + 1, i.e. from the length of the #Strings stream.
Only a small fraction of a #Strings heap is ever read, so the table sat around 11% full — one
nearly-empty table per reference. It is now sized to grow.

memoizeString interned one computed string: the ns + "." + name concatenation in
readBlobHeapAsTypeName. Every caller of that function is already cached or one-shot per row
(typeDefReader, seekReadTypeDefAsTypeRefUncached, seekReadTypeRefUncached, and the exported-type
readers), so the table could only pay when two different rows produce identical text. It went through
Tables.memoize, whose fixed 1000-entry capacity cost about 3.0 MB in buckets across a large reference
set while collapsing at most 0.24 MB of duplicate names — so the table is removed rather than resized.
Tables.memoize keeps its ilmorph.fs caller.

Retained memory after ParseAndCheckProject, mean of 3 runs in fresh processes per project:

Project	Before	After	Retained
consoleapp	33.25 MB	31.11 MB	-2.14 MB (-6.4%)
Oxpecker	69.65 MB	65.77 MB	-3.88 MB (-5.6%)
IcedTasks	47.10 MB	44.93 MB	-2.17 MB (-4.6%)
FsToolkit	69.97 MB	67.86 MB	-2.11 MB (-3.0%)
Fantomas.Benchmarks	64.26 MB	61.33 MB	-2.93 MB (-4.6%)
Prime	100.99 MB	99.44 MB	-1.55 MB (-1.5%)
Fantomas.Core	107.74 MB	106.21 MB	-1.53 MB (-1.4%)
Fantomas.Core.Tests	140.20 MB	137.61 MB	-2.59 MB (-1.8%)
FSharp.Common	261.81 MB	251.68 MB	-10.13 MB (-3.9%)
fcs	1226.73 MB	1223.99 MB	-2.74 MB (-0.2%)

The saving is two tables per reader, so it scales with the number of referenced assemblies rather than
project size: the smallest subject gains most in relative terms, and FSharp.Common, with 489 references,
most in absolute terms. Total allocation drops 1-34 MB per project. Analysis time is unchanged within
measurement noise.

Without the intern table, ~2,077 duplicate name strings survive per FSharp.Common analysis (~0.24 MB,
an upper bound). 98% are one structural pair: the same type def read once as ILTypeDef.Name and once
as ILTypeRef.Name. That is the 0.24 MB the table used to collapse, and it is well below what the table
itself cost.

[github-actions]

❗ Release notes required

You can open this PR in browser to add release notes: open in github.dev

---

✅ Found changes and release notes in following paths:

Warning

No PR link found in some release notes, please consider adding it.

Change path	Release notes path	Description
`src/Compiler`	docs/release-notes/.FSharp.Compiler.Service/11.0.100.md	No current pull request URL (#20261) found, please consider adding it

[T-Gro]

Review — LGTM

Careful, measurement-backed memory work. I traced the change end to end and it holds up.

Correctness

• Removing memoizeString is provably safe. ILTypeRef hashes and compares by value (ILTypeRef.ComputeHash uses hash name; Equals uses x.Name = y.Name), so the identity change from dropping interning cannot affect any dictionary key, lookup, or equality anywhere downstream. The only observable effect is that a type read once as ILTypeDef.Name and once as ILTypeRef.Name becomes two equal-but-distinct instances — exactly the ~0.24 MB you quantified.
• All callers of readBlobHeapAsTypeName check out. typeDefReader/seekReadTypeDefAsTypeRefUncached/seekReadTypeRefUncached all sit behind caches, and the exported-type readers (seekReadNestedExportedTypes, seekReadTopExportedTypes) are one-shot per row inside a lazy. So the intern table could only ever pay on cross-row duplicates, which your data shows are dominated by the single structural pair. The removed field and its only assignment are both gone, and no reference survives anywhere in the tree.
• cacheStringHeap sizing → 0 is fine. mkCacheGeneric false keeps the cache alive (the "lots of cache hits, never optimize away" invariant is preserved); only the initial ConcurrentDictionary capacity changes, and 0 is valid and simply grows. Renaming the now-unused stringsStreamSize to _stringsStreamSize is correct — stringsStreamPhysicalLoc remains the only field consumed from that stream.

Nice properties

• The saving scales with reference count, not project size, which is why the write-up's smallest subject wins relatively and the 489-reference FSharp.Common wins absolutely. That framing matches the code: it's two tables per reader.
• Net negative diff, no new abstractions, and the trade-off (spend 0.24 MB of duplicate names to reclaim ~3.0 MB of fixed-capacity buckets) is clearly the right direction.

One nit (non-blocking)

• The release-note entry is missing the trailing PR link that every sibling line carries:

  * IL: size the string heap cache to grow and remove the type name intern table ([PR #20261](https://github.com/dotnet/fsharp/pull/20261))
  

Great, well-justified change.