[MicroPerf] Avoid Choice allocation in fslib entity/val-ref equality

[T-Gro]

fslibEntityRefEq and fslibValRefEq compare a tuple of refs against the two-case total active patterns |ERefLocal|ERefNonLocal| / |VRefLocal|VRefNonLocal|, which return a heap-allocated Choice. These run for every entity/val-ref equality while compiling FSharp.Core, so the Choice allocation dominates. This replaces those matches with [<return: Struct>] inline active patterns that return a ValueOption (unboxed) and read the ref's local/non-local payload directly — same match shape, no heap allocation.

Measured compiling FSharp.Core with the built compiler (dotnet-trace --profile gc-verbose):

                                          main      PR
Choice2Of2[Entity, NonLocalEntityRef]     746 MB     0
fslibEntityRefEq                          380 MB     0
|VRefLocal|VRefNonLocal|                  123 MB     0
|ERefLocal|ERefNonLocal|                   95 MB     0
total allocated                          7985 MB   6955 MB

The emitted FSharp.Core.dll is byte-for-byte identical to main (deterministic build, SHA-256 unchanged) — ref equality feeds optimization and codegen, so this preserves output exactly.

[github-actions]

⚠️ Release notes required, but author opted out

Warning

Author opted out of release notes, check is disabled for this pull request.
cc @dotnet/fsharp-team-msft

[baronfel]

Out of curiosity, would making the active patterns here ValueChoice instead have resulted in the same allocation savings? In my ideal world, we could use the nice AP features without paying the costs of them!

[T-Gro]

@baronfel : We don't have any ValueChoice , but you are right - we probably should!?

EDIT:
I did change it to the ValueOption variant of APs, but that drops exhaustiveness in case of multiple cases.
A value variant for multiple cases aka ValueChoice is still missing.

[T-Gro]

The problem is the structs might get really big with more cases.
Also, a generic ValueChoice might drop a big optimization potential - for APs where most of the cases (or all) do not carry any data, we might just used a single .Tag integer.