We don't need the split anymore now that we're only supporting Dev15.

Unfortunately this required the introduction of a NuGet package that
has a namespace "Workspace" to our VS project, which meant I had to
disambiguate Workspace wherever it's used in that layer. I considered
doing an extern alias instead to disambiguate, but applying that to a
ProjectReference isn't supported. That's tracked by NuGet/Home#4989.

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.

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.

Our long term goal with asset publishing is to make it a completely
separate step from build. It's an operation which can optional be done
after builds complete. Even being done multiple times if needed to say
work around errors.

Additionally publish should be a deliberate, explicit operation. The
simple act of branching should not publish by default, it should be
explicitly opted into.

This moves us in that direction by doing the following:

- Centralizes our publish story to a single file: PublishData.json in
master
- Makes publish a step that can easily be run on any completed build
- Makes NuGet / VSIX publishing per branch and configurable. Allows for
uploads to many feeds if necessary
- Begins using dotnet/versions to track our packages.

Migrated the remainder of our code base to use the new SDK via the
ConvertPackageRef tool.

https://github.com/jaredpar/ConvertPackageRef

This changes are made by VS whenever Roslyn.sln is opened. Keeping them
as it appears to fix some configuration problems.

In theory this should only insert a build order dependency between these
projects.  Forcing TestUtilities.Desktop to build before the parent
project.

In the new SDK this is treated as an actual reference, not a build order
dependency.  This means that it eventually sees a NetStandard project
referencing a Desktop one and errors out.

Rename Microsoft.CodeAnalysis.Metadata project to Microsoft.CodeAnalysis.Debugging to match the namespace

Fixes #19141

Fixes #18653

Fixes #17921

At this point the Concord project exists just to fix a signing issue in
the Debugger NuGet packages.

This project is causing problems in our port to the new SDK because it's
a Net 45 portable project that is referenced by Net 20 projects.  The
old build silently ignores this incompatibility but the new SDK takes
issue with it, and the method it uses to pass DLLs around.

Taking the simpler approach here of just fixing the signing issues (side
thread going with debugger team) and removing the project.

* remove superfluous use of local function

* add preliminary stack depth finder

* vs changed files

* Use shorter version number for s.c.immutable

This project is no longer necessary.  It used to help us get TDD working fine in Visual Studio.  That's no lonegr needed with the recent build cleanup.  TDD still functions with this project removed.

They were building as 64-bit only since there wasn't a 32-bit CoreCLR before.

Clean up the remaining solutions to have the utilities included.

Add Razor Language Service shim for accessing the remote client

Add Razor Remote Workspace shim for getting access to the solution in
the ServiceHub process. This relies on the same set of Roslyn services
being called by the client to initialize state in the remote process.

Add overloads to the 'remote' solution service to avoid a need for IVT in
in the Razor Remote Workspace shim. Checksum is internal to Workspace.