Allow loading MSBuild into separate AssemblyLoadContext

[twsouthwick]

Currently, the MSBuild assemblies are loaded into the default AssemblyLoadContext. However, I'm interested in being able to load it into a seprate one so I can manage its lifetime separately from the rest of the app.

There are two ways I see this can be added:

1. Replace the call to AssemblyLoadContext.Default to .CurrentContextualReflectionContext (which will require adding a .NET Core 3.1+ target)

#if NETCOREAPP2_1
            AssemblyLoadContext.Default.Resolving += s_registeredHandler;
#else
            var alc = AssemblyLoadContext.CurrentContextualReflectionContext ?? AssemblyLoadContext.Default;
            alc.Resolving += s_registeredHandler;
#endif

2. Add an overload to RegisterMSBuild{xxx}(...) that takes an AssemblyLoadContext

Problems with this:

• Either way, it will only allow loading it into a single AssemblyLoadContext and currently wouldn't understand an assembly load context being unloaded
• Even if it were allowed in multiple assembly load contexts, .NET SDK msbuild instances register environment variables that will continue to be process wide and would therefor potentially cause conflicts if multiple msbuild instances are loaded at once

The first problem is surmountable by changing how it's tracked that MSBuild is loaded. The second issue is something I don't have an answer for.

[rainersigwald]

MSBuild itself has some assumptions about running in the default ALC. I don't think we had a bug for that so I filed dotnet/msbuild#6794.

Until that is fixed, I'm not sure if there's value in changing Locator's behavior, but as soon as it's possible/supported to load MSBuild in an ALC Locator should definitely support/encourage it as well.

[TomKuhn]

This also gets my vote, I have requirements to maintain the lifetime of and unload msbuild from my process when done with it.