The original intent of #12056 was to improve parsing recovery in the
cast of a leading accessibility modifier on a local function. However, I
mistakenly allowed for recovery for an accessibility modifier *anywhere*
in the modifier list of the local function.

This is a mistake because it significantly complicates parsing back-out.
While it's easy to recognize that the local function parsing failed and
skip any leading accessibility modifiers, it's significantly more
complicated to find and skip all accessibility modifiers anywhere in a
sequence of modifiers.

This PR changes the parsing backout to only consider accessibility
modifiers at the start of statements. Any other case will be treated
like other bad modifiers in local functions -- they will be marked as
errors in the declaration list. Fixes #12947.

Related to #12597.

Although I have been able to get the IDE to crash before this change, I don't have a simple repro.

* Don't run the IteratorRewriter on BaseMethodWrapperSymbols

* Removing git link

* Removing extra diagnostics check

* Adding execution test

Fixes #12883

and complete adjustments due to last (incomplete) merge from master.

Previously the syntax generators wrote all of the output into a single file.  That file was quite large and was difficult to use in tools like source.roslyn.io.  Splitting the file into three in order to make that tooling better.

wouldn't that be annoying to notice after we've shipped?

Addresses #12347 

Similarly for TupleDeconstructionVariableDesignation.
Also found many places to handle both kinds of foreach statements.

* MetadataVisualizer: Display table for nil handles

* Harden Literal helpers against bad metadata

* Add support for embedded pdb

* Implement source link feature

* Fix CommonCompiler to open source link stream, add E2E tests

* Reduce code duplication across VB and C#

Also update the out var syntax node to use the newly introduced
VariableComponent so it can be extended in the future to allow `out *`
or `out var (x, y)` etc without requiring any further changes to the
syntax model.
Fixes #12747, #12664, #12588, #1503

The dependency projects serve a few purposes:

- Help ensure package unity by serving as a single place for a NuGet reference.
- Make NuGet updates simple by having a single place to change.
- Grouping together related packages to make it easy to take a dependency on say Visual Studio editor.

The first two points are largely obsolete now that our project.json references are strictly validated on every build and have a single update mechanism.  This meant a lot of our depnedency projects were just making Roslyn.sln bigger.

As such I went through and deleted all of them which had only 1 or 2 project.json entries.  I left the VS ones which tend to group 10+ references together.  They are still serving a valid "reference VS" purpose.

  (e.g. ref local variable declaration)
We introduce a "ref expression" for use in expressions
  (e.g. right-hand-side of a ref variable initialization)
Also improve the diagnostic for local functions.
Fixes #12749, #12580