The Jenkins build is copying Newtonsoft.Json into the output directory.  This is not happening locally and the version chosen by Jenkins is not compatible with the one we are referencing here.  Moving to own output directory to eliminate this issue.

In preparation for moving to web storage.

made solution crawler to prefer project with errors as next project t…

it was due to exception thrown in tests. it looks like that exception is not displayed due to dead lock.

made us to clean up all live errors for projects that built cleanly

Attempt to detect one possible cause for the rename test flakiness

Reduce allocations for IsGeneratedCode analysis in the analyzer driver.

Add new branches to CI configuration

Disable test StackTrace_Dynamic

Merge pull request #8780 from jasonmalinowski/let-miscellaneousfilesworkspace-play-nicely-with-other-workspaces

Change how Miscellaneous Files chooses which documents to track

Optimize allocations in analyzer driver state tracking for syntax tre…

Since WorkspaceChanged is deferred, it's possible for somebody to
register and unregister quickly enough and for us to think we need
to go attach all over again.

We wouldn't correctly handle the lazy tab case otherwise.

AbstractProject had two properties: Workspace and VisualStudioWorkspace
which was very, very confusing. We reduce down to one, and the few
places that needed the derived types

Our previous heuristic is we tracked any document that had a moniker
that wasn't contained within any project in VisualStudioWorkspace.
This was implemented with a private hook between the two systems. This
blows up in the face of other parties wishing to create their own
workspaces against files in the RDT, since we stomp on them. The new
heuristic is we attach to any file that's open and doesn't already have
a workspace, and we watch for registration changes to back off if
something else has taken a file.

Fixes #8598.

Put the CoreCLR test results in a xUnitResults directory

reduce more allocations

Remove dependency on ToolWindowPane

...to expose the IVsWindowFrame for PTVS.

`VsInteractiveWindow` is the concrete implementation of
`IVsInteractiveWindow` that we hand out in the public API.  Since it
extends ToolWindowPane, our public API effectively depends on that type
(since callers can upcast).  Eliminate the dependency by using
composition, rather than inheritance.

TODO: Expose the `IVsWindowFrame` for PTVS.

Merge stabilization into master