This reverts commit 63872019.

This package now only supports the TFM. This is because the purpose of the package
to layout a .NET Core executable, which requires the netcoreapp references, including CoreCLR itself.

There are also numerous references that are now provided by inheritance from the compiler itself, so
those references have been removed from the Microsoft.Net.Compilers.netcore nuspec.

Fixes #12674

This works around #12458. The warnings are annoying and also break
the project system in slightly bad ways.

This reverts commit 760e1204.

This reverts commit e2fc5135.

Synchronize all corefx references to -23504 and bring in the
xunit coreclr test runner.

These projects are executable projects, and already have runtime
sections to get all the right assets deployed. Stating a supports
section is redundant

These references are needed because they are sometimes dynamically loaded at runtime

Csc and Csi are portable projects targeting 5.0 portable
without support clauses, this confuses portable as it
doesn't know the projects target and warns when they
reference other portable projects.

This also enables package validation to ensure that these
projects will never reference a package that doesn't work
on its given targets.

Updating System.Reflection.Metadata to 1.1.0-alpha-0015 and System.Collections.Immutable to 1.1.37.0

Revert "Updating System.Reflection.Metadata to 1.1.0-alpha-0015 and System.Collections.Immutable to 1.1.37.0"

This reverts commit d78dbb97.

Updating System.Reflection.Metadata to 1.1.0-alpha-0015 and System.Collections.Immutable to 1.1.37.0

Reverting System.Collections.Immutable back to 1.1.36 until we can upgrade System.Reflection.Metadata simultaneously

Updating Microsoft.DiaSymReader to v1.0.6, Microsoft.DiaSymReader.Native to v1.2.0, and System.Collections.Immutable to v1.1.37

After updating to the latest CoreCLR NuGet packages we no longer need to
be copying binaries from a drop share to run. This change adds a csc.sh
and a vbc.sh so we can run on the CoreRun host on Linux like we do on
Windows. The change also eliminates some cruft from the cibuild like the
semaphore restore.

Adds a new type, CoreClrAnalyzerAssemblyLoader, that is responsible
for finding and loading analyzer assemblies on CoreCLR. This is used
in the CscCore and VbcCore CoreCLR-targeting projects.

Some of the references were outdated and some of the NuGet packages
were incorrectly authored. With the new references we don't need to
do any extra work to copy over the CoreCLR runtime -- it's copied as
a reference by NuGet 3 without any extra work.

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.

Once System.Runtime.Loader is referenced in the project.json files
a facade is correctly copied to the output directory, so
AssemblyLoadContext can be loaded even if the assembly it's located in
changes.

On CoreCLR we will always be unable to fetch the default encoding and
the 1252 encoding will be unavailable unless we reference
System.Text.Encoding.CodePages. However, we don't want to take a
dependency on this assembly on desktop 4.5 so we now use
AssemblyLoadContext to try to detect whether or not we are running on
CoreCLR and, if so, reflection load the necessary assemblies to get hold
of the necessary types.

This change solves a number of problems that were resulting in
problems compiling Roslyn with Roslyn on the CoreClr.
I believe these problems were being masked by catching
exceptions. The motivation for the changes is to be able
to run Roslyn building Roslyn on Clr using the LLILC jit.
LLILC cannot currently produce code to catch exceptions
so it is important to avoid needless throwing of exceptions.

1. CoreClr was raising FileNotFound exceptions when trying to load the
following assemblies:

```
System.Threading.Overlapped
System.Threading.ThreadPool
```

I added references to these in src/Compilers/CSharp/CscCore/project.json.

2. System.Runtime in the version previously referenced in project.son
had a reference to Internal.Uri. This is no longer the current module
(it has been replaced by System.Private.Uri). So I changed the
version number used in project.json from 22816 to 23109.

3. The path in these ruleset files:

  * src/Compilers/Core/CodeAnalysisRules.ruleset
  * src/Compilers/CSharp/CSharpCodeAnalysisRules.ruleset
  * src/Compilers/VisualBasic/BasicCodeAnalysisRules.ruleset

was "..\..\Tools\Microsoft.CodeAnalysis.Toolset.Open\Rulesets\Roslyn.ruleset"
which is not the current location of Roslyn.ruleset. It now is in
"..\..\..\build\Rulesets\Roslyn.ruleset". The incorrect path
was causing an exception to be thrown.

4. On the CoreClr csc uses a NoOpAnalyzerAssemblyLoader which just
returns null when asked to get the assembly. This was causing a
null reference exception. I added a null check to just return
in this case.

5. The VbcCore project.json was updated to match CscCore.