Also remove osx RID version

Remove the assembly version plumbing as it's no longer needed by our
build.

The Insertion directory is no longer created during our normal build.
Rather it's created as a separate, publishing step that occurs after
build.

Move the build output for Microsoft.CodeAnalysis.Compilers.vsix to the
standard VSIX location. The publish phase of the build now moves it to
the Insertion directory.

After this move the `-buildAll` switch will now build the entirety of
the Roslyn source tree. Previously it didn't build a number of items
related to VS insertion. That layering was arbitrary and mostly due to
limitations in our signing process. Now it can all be done in a single
phase.

Change Microbuild to no longer be forced to use the MSBuild that
Microbuild provides. Doing so means we rely on them to update their
machines when we need updates to MSBuild.

Instead just use our normal mechanisms for discovering MSBuild. This
doesn't depend on machine state.

The compiler tools needed to be targetting netcoreapp2.0 in order to
produce runnable executables.

This primarily moves us to the 2.2.0 version of xunit. In order to make
that transition though a number of other changes needed to happen as
well:

1. Needed to move our desktop target to 4.6.1. This should've been
required some time ago but we were essentially depending on bugs in the
SDK / NuGet.
1. Remove the DeployCoreClrTestRuntime project. This entire idea
depended on having the xunit.console.netcore package. This has since
been deleted and doesn't work with the 2.0 SDK.
1. Remove the deploy compiler tools project. Can just use dotnet exec
now and that's much more efficient.
1. Resolve a new ambiguity with KeyValuePair. A helper of ours now
exists in netcoreapp2.0.

I fully expect a number of Jenkins legs to fail with this change: build
correctness, coreclr and ubuntu. But I want to validate our other legs
and am still trackind down answers needed to fix the others.

Now that we are not tied to roslyn-internal anymore it's possible to
simplify this action a bit:

- Remove the separate script as it's not necessary and can be easily
inlined
- Remove the copy to the root of the source tree. Not necessary anymore
as all our scripts use the returned variable.

Changes BuildBoss to enforce portable test projects use the
UnitTestPortable label. Probably going to remove that in the near future
but at this point it's still required.

* Rename Foo to Goo

* Rename ifoo to igoo

* Add back BOMs

The Roslyn build depends on having a minimum of MSBuild 15.1 in order to
function. Anything less than that will fail with very crpytic errors,
usually around NuGet runtime identifiers.

This change causes our build to declaratively fail with a very specific
message if the wrong version of MSBuild is used. It should help point
customers in the right direction to fixing up the problem.

Note: This was made to be parameterized in Imports.targets because very
soon it will be changing to depend on 15.3.

Portable unit tests now build their desktop variants directly to the
UnitTests directory in a runnable state. This allwos tests to be run
directly and removes the need for the desktop deployment project.

This changes our core Roslyn.Test.Utilities project to use
multi-targeting to control how we create our core compilation helper.
Previously this was done by having a separate runtime specific assembly
which was probed at runtime.

The intent of this change is to make our build more correct here. I can
now target just Roslyn.Test.Utilties with a net46 framework and get a
runnable asset out of it. This is necessary in order for our unit tests
to successfully run when moved to multi-target.

Presently this makes it multi-target across net46, netcoreapp2.0 and
netstandard1.3. The impl in netstandard 1.3 simply throw for this
specific API. Over the long term it make make sense to pull this out to
a separate library that only targets net46 + netcoreapp2.0. That
requires a much deeper investment in multi-targeting though. Decided to
start smaller for now.

By default Invoke-WebRequest will fail if IE hasn't gone through first
configuration setup on the machine. Parts of our infrastructure don't
run IE and as a result our uses of Invoke-WebRequest were failing. Fixed
by passing the UseBasicParsing switch.