Support testhost.exe in TaskHost-launching tests

[rainersigwald]

Some tests were failing when run from Visual Studio because they were running in a .NET 9 process launched as TestHost.exe, not in a dotnet.exe host. That caused TaskHost launching to try to run TestHost.exe MSBuild.dll which failed, as TestHost isn't a general-purpose launcher.

Add another fallback to GetCurrentHost() to fall back to the current shared framework's parent dotnet.exe, if we can find it.

[Copilot]

Pull Request Overview

This PR enhances the host detection logic for .NET processes by adding a fallback that targets the parent dotnet.exe when running under TestHost.exe.

• Changed the return type of GetCurrentHost to allow null values.
• Added a new fallback branch to inspect EnvironmentUtilities.ProcessPath and, if necessary, derive the dotnet.exe path from the runtime directory.

Comments suppressed due to low confidence (1)

src/Build/BackEnd/Components/Communications/CurrentHost.cs:48

• The use of hard-coded folder levels (4) can reduce clarity; consider defining a named constant to indicate the intended directory depth for improved maintainability.

dotnetExe = Path.Combine(FileUtilities.GetFolderAbove(System.Runtime.InteropServices.RuntimeEnvironment.GetRuntimeDirectory(), 4), dotnetExeName);