IL: cache the ILTypeRef of a type def

[auduchinok]

seekReadTypeDefAsTypeRef has no cache. Every call re-reads the TypeDef row, rebuilds the type name,
walks the entire enclosing chain for a nested type, and allocates a fresh ILTypeRef.

Attributing calls to readBlobHeapAsTypeName on a 57-file project with 489 references, 28,073 of 92,665
came through this path — 30%, second only to type-def realisation itself.

This routes it through a per-reader cache keyed on the TypeDef row index, like the adjacent
cacheTypeRef. The result depends only on that row, all of it immutable metadata.

Project	Before (MB)	After (MB)	Diff
consoleapp	33.45	33.28	−0.17 (−0.52%)
Fantomas.Core	107.95	107.72	−0.23 (−0.21%)
Fantomas.Core.Tests	140.55	140.20	−0.35 (−0.25%)
Fantomas.Benchmarks	64.32	64.27	−0.06 (−0.09%)
FSharp.Common	263.81	261.74	−2.08 (−0.79%)
fcs	1230.46	1228.58	−1.88 (−0.15%)

[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:

Change path	Release notes path	Description
`src/Compiler`	docs/release-notes/.FSharp.Compiler.Service/11.0.100.md

[T-Gro]

Verified locally: the cache is keyed on the TypeDef row index and the result depends only on that immutable row (name, namespace, and the enclosing chain, which itself now routes back through the cache for nested types), so this is safe to memoize. Leaving it ungated on reduceMemoryUsage matches cacheTypeRef — the ILTypeRef is retained by the returned structures regardless, so deduping lowers retained memory rather than trading it for speed. All call sites go through the wrapper, and ./Build.cmd -c Debug is clean (0 warnings).

One optional nit: the initial capacity is 0, whereas the sibling caches seed it (getNumRows TableNames.TypeDef / 20 + 1). A hint would save a few rehashes on the hot path, but it's immaterial to correctness.

LGTM.