Support launching .NET taskhost

[rainersigwald]

Extend NodeProviderOutOfProcTaskHost.CreateNode to support launching the .NET MSBuild.dll (in the location from #11330) under a dotnet.exe.

Figuring out which dotnet.exe might be interesting. We should have a clean abstraction to get its path that we can change over time and eventually tie to the one the .NET SDK resolver tells us about from dotnet/sdk#45364 (that is, the result may vary by project on a machine with multiple SDKs installed). This can certainly be prototyped with a more hardcoded value though.

This will also include getting the UsingTask infrastructure to handle the Net identifier from a .NET Framework 4 host, which currently fails (expected, without this feature) with this unfortunate stack dump:

System.AggregateException: One or more errors occurred. ---> Microsoft.Build.Exceptions.BuildAbortedException: Build was canceled.
        MSBuild.exe could not be launched as a child node as it could not be found at the location "C:\Program Files\Microsoft Visual Studio\2022\Preview\MSBuild\Current\Bin\amd64\MSBuild.dll". If necessary, specify the correct location in the BuildParameters, or with the MSBUILD_EXE_PATH environment variable.
  at Microsoft.Build.BackEnd.NodeLauncher.StartInternal(String msbuildLocation, String commandLineArgs)
  at Microsoft.Build.BackEnd.NodeLauncher.DisableMSBuildServer(Func`1 func)
  at Microsoft.Build.BackEnd.NodeProviderOutOfProcBase.<>c__DisplayClass14_0.<GetNodes>g__StartNewNode|2(Int32 nodeId)
  at Microsoft.Build.BackEnd.NodeProviderOutOfProcBase.<>c__DisplayClass14_0.<GetNodes>b__0(Int32 nodeId)

[JanKrivanek]

Btw. not sure if it's relevant here - the OutOfProcTaskHost doesn't support BuildEngine RequestCores/ReleaseCores APIs - if any tasks needs those, they'd get NotImplementedException (shouldn't be that hard to add the support)

[rainersigwald]

That's totally relevant here though I don't know of any core .NET SDK tasks that need it today so we could probably deprioritize it.

[baronfel]

I see several tasks in dotnet/runtime that use this - is this a concern? Do we have a better model for them to pre-emptively migrate to, or does this mean we need to design/implement this correctly?

[rainersigwald]

They'll be running using the netcore engine though so not the cross-framework implementation.

Regardless I don't think there's anything blocking that work besides "find the time to do it".