NuGet restore output is blowing up our log files, so this should output only errors.

This flag was only used to add unecessary differences of behavior
from local developer builds. By removing the flag everything acts
the same.

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.

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.

vcvarsall.bat will call vcvars32.bat, which uses some environment
variables that are not defined. Instead call vsdevcmd.bat, which
*also* uses these environment variable, but we've already patched
up these files on our build systems to work around the issue.

vcvarsall.bat will call vcvars32.bat, which uses some environment
variables that are not defined. Instead call vsdevcmd.bat, which
*also* uses these environment variable, but we've already patched
up these files on our build systems to work around the issue.

Adapted from
https://github.com/jaredpar/roslyn/commit/b239dc009799e16fe6721edc93c727b1a63ecf8a

The cibuild scripts had diverged between stabilization and master. This
change brings stabilization back in sync with master and makes a small
change to ensure passing invalid commandline arguments returns a proper
error code.

The shift command in the middle of this script messes up %~dp0.  Grab script directory at the beginning of the script instead.

This was causing BuildConfiguration to become "Release " or "Debug " and thus the script failed later when copying bootstrap files

Allows for us to properly build a non debug configuration in CI testing

Builds in Jenkins will now self-host the compiler bits that result from
the changes being committed in the PR.  Hence if there is a bug
introduced by the change that prevents us from compiling Roslyn we will
find it out before checkin vs. the next toolset update.

This change causes the Jenkins build to roughly do the following:

1. Build the C#, VB and compiler server binaries and move them to
Binaries\Bootstrap.
2. Clean the enlistment which deletes the intermediate directories and
kill the compiler server.
3. Run our standard BuildAndTest.proj using the
/p:BootstrapBuildPath=Binaries\Bootstrap parameter to self-host the just
built compilers.

Make sure the error checking is done properly.

- msbuild needs to be checked for failure
- taskkill failure shouldn't matter

Instances of vbcscompiler.exe may hang around for a few minutes after a
Jenkins run, locking files and causing new runs on the same system to
fail. To address this, we add a script to setup the environment, run the
build and test, and then kill any instances of vbcscompiler.exe that are
left around.