Merge 15.1.x to 15.2.x

Fixes #17908

(cherry picked from commit 56ec8d17)

Report use-site diagnostics if System.ValueTuple base type is an error type

Report use-site diagnostics from System.ValueTuple base type rather than "'ValueTuple' must be a struct"

Add telemetry to FAR command handler

Add dev15.2.x to Microbuild publish script

Need to pass MSBuild to SignTool in all cases

Merge dev15.0.x to dev15.1.x

Pick the right project for P2P refs in lightweight solution load and cross-targeting

Don't require an invisible editor to be opened when we're locating nodes

The description of this package is vague and incorrect. We now require .NET 4.6, not
.NET 4.5, and that is only a build-time requirement, not a deploy requirement.

Handle FileCodeModel eventing on the foreground thread

NuGet packaging updates for 2.0.0 NuGet packages

Capture better dumps when the contents of linked files don't match

We implement GetStartPoint in a two step process: locate the point
directly from the tree, and then take that point and get an
EnvDTE.TextPoint from it. In the first step we were opening an editable
invisible editor for for no good reason, which was causing us to check
out files from source control. The second step does require an invisible
editor (since EnvDTE.TextPoint is implemented by the shims) but that we
were already opting out of an editable editor for.

Going through source control, we used to open an editor for the first
step because at the time we were grabbing tab settings which required
the editor to be open, but that's no longer the case.

If a project being loaded in lightweight solution load references a CPS project
that does cross-targeting, we may crash trying to hook up P2P references,
because we were looking for a single project matching the project file name, and
language.  In the case of cross-targeting though, we create a project for each
TFM, and the .Single call would blow up.

To fix this, we now continue looking through projects until we find one with an
output path that matches our reference.

Fixes #17570.

Fixes https://devdiv.visualstudio.com/DevDiv/_workitems?_a=edit&id=366045.

CodeModel events (fired when types or members are added or removed,
for example) are handled in a `SolutionCrawler` incremental analyzer.
Actually firing the events needs to happen on the foreground thread,
which we currently do. Some of the setup, including obtaining the
`FileCodeModel` instance, happens on a background thread.

It turns out the `FileCodeModel` must also be obtained on the
foreground thread but we don't enforce this very well. Most of the time
we go down this path the `FileCodeModel` instance has already been
created and cached; in this case we get lucky and don't go down any
problematic paths. However, if we _do_ need to create it then we may
also need to start pushing project data down to the workspace. That can
only happen on the foreground thread, and we *do* enforce it there.

This often manifests as a crash during solution close. Something has
caused the incremental analyzer to run on a background thread.
Meanwhile, the foreground thread is closing the solution, which means
we are no longer pushing project data to the workspace. If the
`FileCodeModel` has not already been cached we'll try to create a new
one and start pushing to the workspace--and then we blow up because
we're on the wrong thread.

Further, the `FileCodeModel.FireEvents()` method returns a bool indicating
whether or not it has more work to do. If it has more work, we need to
post that work back to the foreground thread. Of course, by the time that
subsequent work runs the project or solution may have closed, or the
document in question may no longer exist. So the setup work--mapping from
the `DocumentId` to the `Project` and file path--also need to happen on the
foreground thread.

The fix is to do _all_ the setup work on the foreground thread, and to do
it every time it runs. If the `FileCodeModel` has already been cached things continue to work as before.
If it hasn't, and we try to create it during shutdown then the request
to push to the workspace will fail gracefully. No `FileCodeModel` will
be created, and the incremental analyzer will just bail early.

Avoid deadlock on solution close with linked files

don't convert metadata reference to project reference. this workspace…

In order to gather more information on
https://devdiv.visualstudio.com/DevDiv/_workitems?id=209299, we created
https://github.com/dotnet/roslyn/pull/16918 to capture the text of the
linked documents that aren't in sync. However, we tried to do so by
putting their text in local variables that were optimized away in dumps.

This change introduces a custom exception object that holds onto the
text of the conflicting documents and reports that exception.

Update script dev15.1.x

Merge dev15.0.x to dev15.1.x

Fixes #17305
Fixes
https://devdiv.visualstudio.com/0bdbc590-a062-4c3f-b0f6-9383f67865ee/_workitems?id=388328&_a=edit

Update the Roslyn package version to 2.0.1

We leave the assembly version at 2.0.0 since that's what we do for patch
releases.

don't convert metadata reference to project reference. this workspace replicates workspace in host (VS), it is a bug that it tried to convert metadata reference to project reference.

also, this sometimes caused VS to crash since if a user had circular reference by metadata reference, by converting metadata reference to project reference, we are introducing circular p2p reference in solution, and workspace crash.

Moving the Jenkins jobs to the VS2017 RTW image.

We accidentally shipped a 2.0.0, so we'll have to bump the versions
for the rest of the 2.0.* series.

Something tells me this was copied out of Setup.proj that I wrote ages
ago...

Right now it definitely doesn't build due to pre-release dependencies,
and it's not clear that we'd ever ship non-pre-release versions out
of this repo (or at least versioned with the rest of Roslyn.)

That package is the exact same contents as 0.10.6-rc2 but just repacked.

Merge dev15.0.x to dev15.1.x