.Net - .NET

Update the stub API to remove Nullability and replace with NullableAnnotation and NullableFlowState, and update the
the rewriter to use that instead of the Nullability enum.

This has shown up as a hot allocation path in a few different traces.
This change amortizes the allocations by using a pooled ArrayBuilder
instead of allocating a new Stack every time.

The following benchmarks seem to support the hypothesis:

Before change:

```
BenchmarkDotNet=v0.11.1, OS=Windows 10.0.17134.590 (1803/April2018Update/Redstone4)
AMD Ryzen 7 1800X Eight-Core Processor (Max: 3.60GHz), 1 CPU, 16 logical and 8 physical cores
.NET Core SDK=2.2.103
  [Host] : .NET Core 2.1.8 (CoreCLR 4.6.27317.03, CoreFX 4.6.27317.03), 64bit RyuJIT
  Core   : .NET Core 2.1.8 (CoreCLR 4.6.27317.03, CoreFX 4.6.27317.03), 64bit RyuJIT

Job=Core  Runtime=Core  Server=True

                Method |      Mean |     Error |    StdDev |     Gen 0 | Allocated |
---------------------- |----------:|----------:|----------:|----------:|----------:|
               Parsing |  65.25 ms |  1.301 ms |  2.568 ms |         - |   6.57 MB |
 CompileMethodsAndEmit | 634.00 ms | 12.640 ms | 22.468 ms | 1000.0000 |  40.29 MB |
     SerializeMetadata | 200.52 ms |  3.656 ms |  3.241 ms | 1000.0000 |  17.39 MB |
```

After change:

```
BenchmarkDotNet=v0.11.1, OS=Windows 10.0.17134.590 (1803/April2018Update/Redstone4)
AMD Ryzen 7 1800X Eight-Core Processor (Max: 3.60GHz), 1 CPU, 16 logical and 8 physical cores
.NET Core SDK=2.2.103
  [Host] : .NET Core 2.1.8 (CoreCLR 4.6.27317.03, CoreFX 4.6.27317.03), 64bit RyuJIT
  Core   : .NET Core 2.1.8 (CoreCLR 4.6.27317.03, CoreFX 4.6.27317.03), 64bit RyuJIT

Job=Core  Runtime=Core  Server=True

                Method |      Mean |     Error |    StdDev |     Gen 0 | Allocated |
---------------------- |----------:|----------:|----------:|----------:|----------:|
               Parsing |  67.26 ms |  1.344 ms |  3.321 ms |         - |   2.59 MB |
 CompileMethodsAndEmit | 627.23 ms | 13.307 ms | 23.995 ms | 1000.0000 |  28.85 MB |
     SerializeMetadata | 206.02 ms |  4.087 ms |  5.991 ms | 1000.0000 |  17.39 MB |
```

Reflects the changes described in https://github.com/dotnet/csharplang/pull/2214.

Range now looks optimistically for some special members with optional
parameters, but will fall back to the Range constructor if they aren't
present.

This change also removes all of the specialized codegen that was going
on with arrays and strings in favor of expected helpers or real members.

This change enables C# 8.0 use in the code base as well as moving the
recommended Visual Studio version to 2019 Preview 4.  The following
features are now allowed to be used:

- `switch` expressions
- recursive pattern matching
- `using` declarations
- `static` local functions
- local / parameter shadowing in local functions / lambdas
- `null` coalescing assignment
- `async` streams: keep this out of our public API surface for now as we
don't want to block unification with netcoreapp in the future.

Before getting into the features which are off limits I wanted to
outline how compiler toolsets work in this repository. There are three
toolsets we need to consider when adopting new features:

1. The compiler toolset which provides the IDE experience: Intellisense,
syntax highlighting, etc ...
1. The compiler toolset which is used when the solution is built. This
is explicitly different than the compiler toolset which ships with the
MSBuild driving the compilation.
1. The compiler toolset is built from source on every PR and used as the
toolset for the PR (overriding 2 above).

That being said the following features are offlimit for now:

- Index / Range: the API surface area, including the parts the compiler
depends on, underwent significant churn for .NET Core Preview 3. Until
we converge it means toolsets 1 and 2 can be a bit out of sync.
- `unmanaged` generic `struct`: this is not included in VS2019 Preview 4
and hence using it would make the IDE experience poor.
- Nullable Reference Types: this area is under active churn and we could
easily get into a situation where toolsets 2 and 3 disagreed on code
checked into the repository creating unmergeable PRs. As such we're
holding off on this in master for now. Until then please use the branch
[features/NullableDogfood](https://github.com/dotnet/roslyn/tree/features/NullableDogfood)
to dogfood NRT. This will be merged back into master closer to
Dev16.0GA.

Note: This change only affects the C# compiler toolset. There are no
changes to our MSBuild or .NET Core SDK toolsets. Those will be coming
soonish though.

This change does two things: shrinks the required Index/Range APIs to
a minimal set, and changes the new required API names to those decided
in the latest CoreFX design review 
(CoreCLR change at https://github.com/dotnet/coreclr/pull/22331).

WpfSharedTestData had two static members: Instance and
TestSerializationGateName. TestSerializationGateName is the name of a
system-wide Semaphore that was used to execute WpfFacts one at time.
The intent is this was a GUID so it wouldn't actually be shared.
Unfortunately, the Instance member is initialized first; and the
non-static Semaphore field is initialized with the still uninitialized
TestSerializationGateName. This means our Semaphore would always be
named with a GUID of all-zeros, causing us to share the semaphore
between all running xUnit processes. This was terribly bad for
two reasons:

1. It kills test performance. We run tests in parallel in separate
   processes to ensure isolation, but this sharing of the semaphore
   meant that all of those processes are only running one test at a
   time, defeating all running of tests in parallel.
2. If one test process crashes, the Semaphore is never freed, meaning
   all your other test processes will deadlock and never complete.

It's unclear why this code is using a Semaphore, but since we have
no need to share the Semaphore between processes, we can use a
SemaphoreSlim. This also has the added benefit of properly supporting
a WaitAsync that isn't implemented by launching off a Thread just to
wait for the system semaphore.

- Move the generated chek into the syntax tree
- Pass isGeneratedCode to both nullable directive map and warning state map
- When isGeneratedCode is true, add nullable disabled state to the start of the warning map
- Add extra tests
- PR feedback

Fixes VSO Watson [#763828](https://devdiv.visualstudio.com/DevDiv/_workitems/edit/763828)
All the dumps for the watson show that cancellation was requested during analysis, leading to one thread clearing state while other thread faulted.

Part of #33018

This is a reworked version of #32616 targeting the dev16.0-preview3 branch.

Fixes #32216

* Remove obsolete comment.
Fixes #32315

* Add additional verifications in tests for recursive patterns.
Related to an issue in https://github.com/dotnet/roslyn/issues/32012

We invoke symbol end actions for named type symbols after symbol callbacks have been made for all its member symbols. However, we did not account for both parts of partial methods, which means we would end up with a symbol end callback for a named type prior to the partial implementation part being analyzed. This caused the remove unused member analyzer in IDE to incorrectly flag private members referenced in partial methods.

Fixes #32702

https://github.com/mono/mono/issues/12603

Fixes https://github.com/dotnet/roslyn/issues/20118