Fixes - #8951

This reverts commit e3c1ea08.

This still only runs the tests on desktop (for now), but it makes
it possible to run them on coreclr.

They are no longer needed.  Time to remove them.

* This updates all references to nuget.exe to use the copy in the root.
* This deletes all NuGet.config and NuGet.exe files that are not in the root.
* This removes all references to NuGet.targets (which is obsolete and no longer exists)

Rogjt mpw we build a boostrap version of csc and vbc and bootstrap
with those running on Mono. This commit switches us to build a CoreCLR
compatible csc and then running the boostrap on CoreCLR

Right now the full set of Linux CoreCLR runtime assemblies is not
available on NuGet, so we substitute with some assemblies we stash in
our NuGet ZIP package.

Move TestUtilities.csproj and TestUtilities.FX45.csproj to separate directories to accomodate current nuget limitations

It's confusing for new users to have the Roslyn solutions nested
inside the src/ directory and there's really no good reason those where
there in the first place. This moves them to the root directory, except
for the Toolset.sln solution, which is only for building Roslyn in CI
scenarios and has been moved to the build/ directory.

This deletes the empty and unused Desktop assemblies from the code base.

Created a cross platform solution

This solution file contains the set of projects which we support
building cross platform.

Note: ideally this would be the same as Toolset.sln.  However there are
certain dependencies which we simply can’t use cross platform at the
moment (MSBuild in particular).  Eventually these two solutions should
converge if possible.

Fix stack overflows when running in Mono

Several of our test suites have cycles between static field
initializers and the containing types constructor.  The mono runtime
ends up stack overflowing on these cycles and prevents us from running
suites.  Changing the suites to remove this cycle via lazy field
initialization.

It now encompasses the actual toolset portion of Roslyn.

Now that the comment formatting issue is fixed in the Formatter type, we can run the formatter on the remainder of the VB code base.

closes #1424

# The first commit's message is:
Move csc2/vbc2 logic into csc/vbc behind '/shared' flag

This change adds support for the '/shared' flag to csc/vbc, which indicates
to the command line compiler that it should attempt to use the compiler server.

This change doesn't yet delete the csc2 and vbc2 binaries to preserve compatibility
for our partners until they have a change to switch to the new API.

# The 2nd commit message will be skipped:

#	Address CR comments

# The 3rd commit message will be skipped:

#	More CR comments

Produce invisible / suggestion squiggles (which will in turn display Quick Info on mouse hover) for the hidden diagnostics that we report for 'Remove Unnecessary Usings' and 'Simplify Type Name'. The presence of Quick Info pane for such squiggles allows allows platform to display Light Bulb for the corresponding fixes. Per their current design platform can only display light bulb if Quick Info pane is present.

This deletes the csc2, vbc2, NativeClient, and VBCSC2UI native projects
and replaces the functionality with the managed client implementation in the
build task. At this moment the functionality of the compilers should be
identical to what is currently shipping, but using 100% managed code.

We need to produce two copies of each ResultProvider DLL, one that runs on
NetFX20 and one that is Portable.  We originally believed that we could
create a single DLL that would work for both and so we just copied the
output of each ResultProvider project and signed it with a different
Authenticode certificate.  Now we know that - even though the source of
both versions will be the same - we need to actually recompile for
Portable.

As a first step, we eliminate the copying mechanism and split each
ResultProvider project in two.  To minimize duplication, we introduce
shared projects that hold on to most of the source.

The next step will be to make the two copies reference different
assemblies.

This change moves Roslyn2013.sln to work with Visual Studio 2015 CTP6.
This allows customers, and Jenkins, to build and test significantly more
code than was available with the old solution.

This is still not as full Roslyn.sln because not everything is buildable
against CTP6.  In particular our Visual Studio components and all of
their dependencies can't build due to API changes we depend on that came
into being after CTP6.  It is much closer though than our previous
solution.

As a part of this change I also renamed Roslyn2013.sln to
RoslynLight.sln.  The 2013 moniker was no longer valid and lacking a
better word I chose light (it has less projects and hence is lighter).

This change reduces the VM used and memory allocated in the emit
tests by moving the WinRT tests to their own DLL and removing
the extra mscorlib reference.

The cause of most of the allocations in the Emit unit tests was
serializing the WinRT assemblies across app domains. There were
three reasons the DLLs needed to be serialized:

1) PeVerify currently requires a separate app domain to be used if
   any of the references of the assembly to be verified have already
   been loaded into the current app domain and have a different MVID.

2) The WinRT tests all use a separate version of mscorlib, so they
   will all reference an assembly with a different MVID than the one
   loaded.

3) Most of the WinRT tests were accidentally pulling two references
   to mscorlib, also always leading to a conflict.

All of these issues should be resolved. The CSharp.Emit unit tests
now allocated 400 MB less and have > 100 MB smaller peak VM.

Fixes #386.

Currently tests are run on the developers machine using

> msbuild BuildAndTest.proj

This takes ~25 minutes to complete on the CI machine and ~45 minutes on
a developer machine (developer machines run a greater number of suites).
This is not conductive to quick bug fixes.

Ideally the infrastructure would switch over to using xunit 2 which can
handle parallelizing the tests for us.  Unfortunately this isn't an
option because:

1. The 32 bit runner quickly OOMS on our suites
2. A number of our tests can't run in 64 bit

Long term xunit2 is still our goal.  Short term though this tool will
use process level parallelization to run our suites.

The Open directory contains several projects that rely on having a compatible version of Visual Studio 2015 installed in order to build properly.   At this time there is no version of Visual Studio that will work over the long term that we can ask customers, and Jenkins, to move to in order to edit and build Roslyn.sln on master.  Our dependency on the VS SDK just evolves too rapidly.

After some discussion I decided to put two solution files into the repo:

     - Roslyn2013.sln:  This solution is usable on a machine with only Visual Studio 2013 installed.  This unfortunately won't contain all of the new items we are releasing but at least gives customers a stable base to iterate on.
     - Roslyn.sln: This solution contains every project we've released and will work with some builds of 2015.  Likely it will work with the most recent CTP but I have not verified that (just don't have the right setup to do so).

The long term plan here is to always be able to edit, build and debug the master branch with an RTM version of Visual Studio.  But until we hit RTM (or really RC) of Visual Studio 2015 we are going to have a hybrid solution to keep both us and customers productive.   (changeset 1405691)