Allow netcoreapp agent to work with non-standard dotnet install locations

[ChrisMaddock]

Ref: #937 (comment)

Launching a netcoreapp agent currently relies on dotnet being installed in the default location. It could be good to look at alternatives that do not require that, possibly using dotnet --list-runtimes.

If we do go ahead removing inprocess running, this may become an issue for the adapter - in that I suspect dotnet test currently supports non-default-location installations of dotnet, which we would break if agents needed to be launched.

[CharliePoole]

@rprouse @mikkelbu @jnm2 @OsirisTerje
This is a small can of works, but a can of worms none the less. I'm going to outline the approach I imagine here along with some assumptions and I'd appreciate comments. @rprouse Maybe the framework team should be pointed to this as well, since they are clearly affected and there's more folks there.

Assumption

When different install locations are used for different versions of .NET, we assume that each location is intended to be independent of the others. For example, if I set up a special non-standard location for a .Net 7.0 RC, I want to test with only that framework available. If I want others, like .NET Core 3.1, to be available, I'll re-install that framework using the same non-standard location. Based on my experiments, I believe this is what the dotnet team intended, but I'll be happy if someone is in a position to contradict me. :-)

Implementation

1. Execute "dotnet --info" and capture the output.
2. Parse out the Host information, which includes the version of dotnet used for the command and the architecture.
3. Parse out the listed runtimes and create a list.

Note: If we are running under an isolated runtime download, not specified in the registry, our list will not contain the standard installation on the machine. Unfortunately, this is exactly the situation we are in when we run our CI.

4. Under Windows, check the registry to find the install location for dotnet. This resolves the stated purpose of the issue. Continue (for now) to use a hard-coded directory for Linux.
5. Use that directory to find runtime versions installed just as we now do, but incorporate the architecture we are actually using in the paths rather than hard-coding it. Add those versions to the list if they are not already on it.

NOTE: Scanning the directories guarantees that NUnit knows about all available runtimes even when running under an isolated installation. It may be possible to introduce some heuristics to skip this step but I want to include it initially to be sure.

I'd definitely like to hear of any problems you see in this approach, but it seems to me that it should work fairly well. The runner will know about all runtimes installed in the normal way plus any isolated runtimes installed for testing, as we do for the 7.0 RC release.

[CharliePoole]

I have implemented this as described, allowing our own tests on AppVeyor to use an isolated installation of .NET 7.0 RC located on its path, while still accessing the versions of the runtime installed in the normal way. For 4.0, we may want to reconsider this approach since it's quite possible that some users may want an isolated installation to remain isolated for testing purposes.

[CharliePoole]

This issue has been resolved in version 3.16.0

The release is available on:
GitHub.
NuGet packages are also available NuGet.org and
Chocolatey Packages may be found at Chocolatey.org