Closes #32540.
Closes #33083.

* Add support for virtual properties with a private accessor in an interface

Relevant LDM notes https://github.com/dotnet/csharplang/blob/master/meetings/2018/LDM-2018-10-17.md

Merge 'dotnet/master' into DefaultInterfaceImplementation

This is a follow up on https://github.com/dotnet/roslyn/pull/33281.

Add long paths support

Ensure that MSBuildWorkspace deals with duplicate ProjectReferences

* Add initial support for specifying explicit base type in the base access.

Relevant LDM notes https://github.com/dotnet/csharplang/blob/master/meetings/2018/LDM-2018-11-14.md .

* PR feedback

Merge dev16.0 to master

Update formatter

Delete unnecessary code around Workspace eventing

Fix compiler crash and remove spurious hidden sequence points for switch expression

* Update PublishData.json

Change lab/ml to master now that we're inserting our 16.1 payloads into VS master

* Add vsMajorVersion

This is needed for building VS bootstrapper for IBC training.

- Fix parsing regression of expressions involving parens when used as a case expression or a constant pattern.
Fixes #33054
Fixes #33208
- Incidentally also correct and test the precedence of the switch expression
See https://github.com/dotnet/csharplang/blob/master/proposals/patterns.md#switch-expression for the spec.
- Fix terminology to match the spec - "conditional expression" rather than "ternary expression".

Fixes #32774

Add more information on running tests from the command line, and view…

Update .editorconfig

Expand RemoveAllComments to have more in depth logic and handle more corner cases in csharp

These assemblies target netstandard1.3, not 2.0.

`vsBranch` is the VS branch that the Roslyn branch inserts to
`ibcSourceBranch` is the Roslyn branch that produced IBC data that should be consumed by official build of the branch. If not specified it's the branch itself.

Resolve Metadata As Source symbols in their original compilations

Merge dev16.0 to master

Ensure we write logs xUnit logs and dumps in a place where we will archive them

We had some code in the VS layer that was trying to work around the
fact that we might be MEF created on a background thread, when were
didn't know what the UI thread was. It tried to assert that the first
actual workspace mutation would happen on the UI thread, and so it was
safe to create the queue at that point. This is silly now for two
reasons:

1. We're using the IThreadingContext which knows what the main thread
   is directly and without any ceremony
2. We now do indeed do workspace mutations on other threads. It's still
   the case that the first mutation is on the UI thread today but that's
   a limitation we are actively wanting to excise.

Merge dev15.9.x to dev16.0