Use SDK from bootstrapped CLI rather than testhost

[ericstj]

Port dotnet/corefx@dd2ad43

This also removes copying the SDK to the testhost directory
since that is no longer needed.

[ViktorHofer]

We should log the test failures before merging.

[davidsh]

This PR looks interesting. :)

Will it make it easier to run any random .NET Core app I have where I run it with 'dotnet run' and use my privately built .NET Core runtime instead of the globally installed one?

Currently, when I want to run an existing app against my 'master' built .NET Core, I have to manually copy/change files into the existing /usr/share/dotnet/shared/Microsoft.NETCore.App/3.0 folder (or Windows equivalent).

[ericstj]

This PR is just restoring the behavior we had in CoreFx that enables Visual Studio's test explorer to activate the shared framework we create under artifacts\bin\testhost.

when I want to run an existing app against my 'master' built .NET Core, I have to manually copy/change files

@davidsh You should be able to use the shared framework we stage as part of the build for testing. Check under artifacts\bin\testhost. If you use this dotnet.exe to start your app, and you set the DOTNET_MULTILEVEL_LOOKUP=0 it will force it to run against that shared framework. If you have an app with an Exe (or COM component) that you'd like to use this shared framework you'll also need to set DOTNET_ROOT, since those cannot base their probing off the location of dotnet.exe.

[ericstj]

FileSystemWatcher failure on mac is https://github.com/dotnet/corefx/issues/38966. I added a pointer to the issue.

Crossgen failure looks like a problem with that test. It's not failing and not reporting any results. @ViktorHofer do you know what the deal is with that?

[safern]

Crossgen failure looks like a problem with that test. It's not failing and not reporting any results. @ViktorHofer do you know what the deal is with that?

@jashook is currently investigating that failure.

[ericstj]

In that case will merge as failures are understood