Use matching local FSharp.Core for regression builds

[majocha]

Summary

This PR updates the local-compiler regression shim so it uses the locally built FSharp.Core in a way that matches the consuming project's target framework, instead of forcing a single global core choice.

What changed

• Adjusted UseLocalCompiler.Directory.Build.props so the shim selects a matching local FSharp.Core asset based on the project target framework.
• For older/legacy targets (for example .NET Framework and netstandard < 2.1), the shim uses the local netstandard2.0 FSharp.Core build.
• For modern targets (for example net8.0/net10.0), the shim uses the local netstandard2.1 FSharp.Core build.
• The shim now removes existing FSharp.Core references from the build graph and replaces them with the matching local assembly during assembly resolution, avoiding version conflicts with package-based FSharp.Core references.
• The override is now idempotent, so the same local core path is not added twice and the build does not trip over duplicate reference entries.
• If the matching local FSharp.Core artifact is missing, the build now fails loudly instead of silently falling back to the wrong assembly.

Why

The regression-test harness needs to test the locally built FSharp.Core, but it must do so in a way that is compatible with the project being built. The previous behavior could force the wrong FSharp.Core flavor for some projects and lead to build failures, assembly-version conflicts, or duplicate-reference issues.

Validation

I validated the new shim locally with two smoke builds:

dotnet build tests/projects/CompilerCompat/CompilerCompatLib/CompilerCompatLib.fsproj -c Release -p:LoadLocalFSharpBuild=True -p:TargetFramework=net8.0 -v:minimal

and a temporary repro project that explicitly references FSharp.Core 10.0.100 to mirror the CI failure mode:

dotnet build ShimRepro.fsproj -c Release -p:LoadLocalFSharpBuild=True -v:minimal

Both completed successfully without the FSharp.Core conflict or duplicate-reference issue seen in CI.