Cut allocations in the VS project options caches and drop a boxing check

[xperiandri]

Three independent allocation cleanups, one per commit, no behaviour change.

DelayedILModuleReader.result — declare it nullable instead of boxing

The field was declared non-nullable and initialised with Unchecked.defaultof<_>, so both the fast path and the inside-the-lock recheck had to box it just to test for null. Typing it ILModuleReader | null lets match narrow the type directly and drops the boxes.

This is confined to the private field; the public DelayedILModuleReader surface is unchanged.

Array.tryPickV + IProjectSite.CompilationBinOutputPath

CompilationBinOutputPath is probed for the -o: flag on every project-site mapping and its result is immediately turned into a string or null. Added an Array.tryPickV next to the existing Array.chooseV and changed the (internal) IProjectSite member to string voption, so neither the pick nor the result allocates. Call sites move from Option.toObj to ValueOption.toObj.

IProjectSite here is Microsoft.VisualStudio.FSharp.Editor.IProjectSite, which is internal; the identically-shaped Microsoft.VisualStudio.FSharp.LanguageService.IProjectSite used by the legacy project system and Salsa is untouched.

Struct tuples for the project options caches

FSharpProjectOptionsReactor's commandLineOptions and project options cache dictionaries, and the AsyncReplyChannel payloads of TryGetOptionsByDocument/TryGetOptionsByProject, all carried reference tuples allocated on every cache write and every reply. None of them escape the reactor, so they are now struct tuples.

Validation

FSharp.Compiler.Service and FSharp.Editor both build clean in Debug.

---

Update: this PR originally also included a small IlxGen.fs change (HashRangeSorted and two @ concatenations rewritten to avoid intermediate lists). It's been reverted (see the "Revert the IlxGen.fs list-creation micro-optimization" commit): CI's ILVerify job flagged FSharp.Compiler.IlxGen::HashRangeSorted with a StackUnexpected error in Release builds that didn't match the checked-in baseline, even though the identical error text is already present in that baseline as a known, pre-existing issue. I could not pin down the exact mechanism locally (a byte-identical origin/main IlxGen.fs reproduces the same baselined error through the same build path, but a partial revert didn't clear the CI mismatch either), and the allocation savings there were marginal — not worth the risk of shipping IL that ILVerify disagrees with in a shipped compiler DLL. Happy to revisit that piece separately with more thorough (bootstrap-build-equivalent) local verification.

[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
`vsintegration/src`	docs/release-notes/.VisualStudio/18.vNext.md

[T-Gro]

Three correct, low-risk allocation cleanups — the struct-tuple swap is safe under ConcurrentDictionary's node replacement and the nullable-field change is semantically identical. No open threads. I'm fine taking the small FSharpCheckerResults.fs change along with the VS cache work rather than splitting it. Thanks!