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.

Adds two new projects, CscCore and VbcCore, which target CoreCLR and
produce CoreCLR-compatible executables in the core-clr subdirectory of
the build output. At the moment they are not included in any solution
because a bug in the DNX build tools that causes VS 2015 to deadlock
whenever the project files are loaded.