Fixes#5158
Context
A task author can force any task to run out of process by specifying that it must run with TaskFactory="TaskHostFactory". But we never made this work on .NET Core; it fails with an error like
S:\msbuild\foo.proj(8,5): error MSB4216: Could not run the "Message" task because MSBuild could not create or connect to a task host with runtime "CLR4" and architecture "x64". Please ensure that (1) the requested runtime and/or architecture are available on the machine, and (2) that the required executable "S:\msbuild\.dotnet\sdk\6.0.100-rc.1.21458.32\MSBuild.exe" exists and can be run.
That's because the "default" task host runtime was hardcoded to be CLR4 (even when on .NET 6.0+).
Changes Made
Created GetCurrentMSBuildRuntime() and used it; plumbed the new value around and checked for it in a few places. Eliminated FEATURE_TASKHOST since it's on everywhere now. Unified the named-pipe-name computation code (before it was using a different pipe name for taskhost pipes on UNIX).
Testing
Re-enabled tests for this behavior that have been disabled on .NET Core. Extended some to account for the NET runtime.
Specific steps:
* Enable out-of-proc TaskHosts on .NET Core
* Promote FEATURE_TASKHOST to no-flag-needed
This enables taskhost tests on .NET Core. Includes a couple of low-
complexity test fixes.
* Enable checking runtimetype in .tasks file
* Check runtime type in tasks file
* Extend TestRuntimeValuesMatch for net
* Extend RuntimeValuesMatch for net
* Split and shouldly-ify TestMergeRuntimeValues
* Use explicit current runtime/arch in CreatableByTaskFactoryMatchingIdentity
* Unify to NamedPipeUtil.GetPipeNameOrPath
Rainer Sigwald