F# Scripts: Fix resolving the dotnet host path when an SDK directory is specified

[DedSec256]

The FSharpChecker.GetProjectOptionsFromScript method has an optional parameter sdkDirOverride, which allows specifying the SDK with which the script will be analyzed in the IDE. However, for restoring NuGet packages, this info is not used, which leads to some unpredictable behavior. In some cases, for example, when using a new version of .NET installed in a non-standard location, restoring NuGet packages becomes impossible with an error like

error NETSDK1045: The current .NET SDK does not support targeting .NET 9.0. Either target .NET 8.0 or lower, or use a version of the .NET SDK that supports .NET 9.0

This PR fixes this issue, taking into account the sdkDirOverride parameter for NuGet restoring in the default FSharpDependencyManager.

It also improves additional log info in the generated Project.fsproj.fsx, showing the correct path to the used dotnet.exe instead of the outdated hardcoded.

[github-actions]

❗ Release notes required

---

✅ Found changes and release notes in following paths:

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

[T-Gro]

I get the intention.

But still, I believe future human and non-human coders would appreciate a few comments about what is being done here and especially why.

[T-Gro]

What changes, docs or implementation or some limited guidance perhaps, are to be done towards 3rd party Dependency Providers together with this change?

In this case, the purpose (fixing nuget, the dominant provider) is justified and I think it's OK to expand the possibility of sdkDirOverride to other providers - do I understand it right that now every provider can retrieve this info?

(I am coming from a philosophical question if a direct string param is correct here and if it does not close too many future-expansion points.

After all, the construction logic is driven via constructor overloads and locking down string option as a constructor argument might be kick as back later.

Have you considered ways of making this parameter more semantic, either by changing construction logic or by also utilizing the parameter's name on top of the GetConstructor search perhaps?)