* Use DSRN version 1.7.0-beta-25631

* Fill in missing document entries in PDB tests

* Update pdb to xml converter to 1.1.0-beta1-62106-02

* Full Windows PDB determinism

* Update DSRN to 1.7.0-private-25621

* Avoid caching zero chunks

* PR feedback

This is at least temporarily using `dotnet vstest` to execute the tests.
That allows us to run the tests but can't do things like generate
compatible XML files that Jenkins can process.

The new structure of the tests does mean that our Linux / Mac jobs are
now broken though since we no longer have the deploy project.

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.

Changes:

- Move to new MSBuild toolset that supports resolvers.
- Handle the case where %PATH% contains an empty entry.

This reverts commit 1f4221b0, reversing
changes made to d8f3eeb5.

Update to Microsoft.DiaSymReader.PortablePdb, Microsoft.DiaSymReader.Converter.Xml to 1.4.0-beta1-62016-01 (#21557)

Include System.Runtime.Serialization.Primitives and System.Security.Cryptography.Csp in PortableFacades CoreXT package. (#21438)

Move to a new Roslyn analyzer package that does not contain the crashing CA2242 analyzer due to the breaking IOperation API change.

* Compare lines instead of using AssertXml when validating PDBs.

AssertXml doesn't validate ordering.

* Reorder expected PDB XML nodes to match actual order

* Update to the latest Microsoft.DiaSymReader.* packages.

* Enable embedding sources to Windows PDBs

Breaks the internal GTD infrastructure into seperate symbols for
determining the navigable symbol at the caret position and performing
the navigation.

The Roslyn build depends on having a minimum of MSBuild 15.1 in order to
function. Anything less than that will fail with very crpytic errors,
usually around NuGet runtime identifiers.

This change causes our build to declaratively fail with a very specific
message if the wrong version of MSBuild is used. It should help point
customers in the right direction to fixing up the problem.

Note: This was made to be parameterized in Imports.targets because very
soon it will be changing to depend on 15.3.

The most recent preview of 15.3 introduced a number of NuGet warnings
into our build. Most of these were due to new dependencies in the
service hub layer. This change fixes these warnings by moving to a new
version of StreamJsonRpc and adding new PackageReferences as dictated by
the warnings

Relevant links:

- https://github.com/NuGet/Home/issues/5633
- https://github.com/NuGet/Home/wiki/Warnings-and-Errors-Combined-Specs

Fixes #21050

Move to newer version of Microsoft.Net.Compilers and Microsoft.NetCore.Compilers compatible with latest analyzers package

The [change](https://github.com/dotnet/roslyn/commit/6be56fadb4c417c4b6af0bf62f1242e41c8dd124) to move analyzers to 2.5 version broke analyzers in the branch - they are laid out differently in the new nuget package. Build targets are unable to find the props for importing the analyzers and silently bail out executing them. This PR fixes the following:

1. Fix the props file path in Imports.Targets
2. Move to a newer analyzer package which has an important [bug fix](https://github.com/dotnet/roslyn-analyzers/pull/1255)
3. Report a build error if analyzer props file does not exist
4. Fix the public API errors (mostly due to duplicate entries in shipped and unshipped files).
5. Fix one instance of RS0014 (Do not use Enumerable methods on indexable collections. Instead use the collection directly) introduced recently in the code.
6. Add suppression for one instance of CA1802 in WellKnownAttributeData.cs that fixed the signing issue.

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.

This version of the build tools has better error tracking for installation failures.

Reviewing some code today I realized the bootstrap build was only
running for our deterimnism suites, not for unit tests.

Fixing that required that I also update the analyzers + base toolset
package being used. The analyzers package is tied to major + minor versions
of the compiler presently. This means in order to function our base
toolset and bootstrap build must have same major + minor version.

Invoke the new DoubleWritesAnalyzer API and remove code that was doing the same thing.

The paths in MSBuild use a mix of `/` and `\\`. The normalization to one
or the other happens very late in tool task execution. It's still very
visible during execution of most tasks in our targets files.

This means the comparison in BuildUtil must account for this.