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.

I verified that this test crashes the compiler in Preview3
but no longer repros.

Fixes #33537

Marshal.SizeOf is not a direct replacement for `sizeof` and the issues around it are subtle.

Fix #26513

* Nullability for NVT with no constructor argument:
- Explicitly check if an object creation is a nullable value type
- Set its state to nullable when it is the default constructor that is being called
- Update tests

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.

* Add reproducer for #33388

* Skip normalizing task types if binding attribute arguments

* Use InAttributeArgument property

* Add test where task-like normalization affects overload resolution

* Update AttributeArgument_TaskLikeOverloadResolution test case

* Add assert and remove apparently unused branch

* Add back comparison of remaining parameter types with InAttributeArgument guard

* Update comment on remaining parameter comparisons

* Add comment describing why we don't normalize task types in attribute arguments

* Store nullable attribute constructor params in a field:
- Add a derived nullable attribute symbol
- Add a constructor symbol that allows assignment to a field
- Generate the appropriate constructors for byte and byte[] versions of the attribute
- Add tests

The NullableWalker is revised so that the inferred state of an expression is either `NotNull` or `MaybeNull` (represented by the new type `NullableFlowState`).  There is no longer such as thing as an oblivious rvalue.  There are four kinds of lvalues:
- oblivious lvalues read as NotNull but null can be written to them
- annotated lvalues read as MaybeNull and null can be written to them
- unannotated lvalues read as NotNull and null may not be written to them
- unconstrained type parameters read as MaybeNull but null may not be written to them

In order to preserve the safety in the face of such unconstrained type parameters, we warn immediately when a null value of such a type is introduced.  This is a safety warning.  The contexts in which such a warning are given are
- `default` and `default(T)`
- `null` conversion to `T` (when `T` is known to be ref type)
- `e?.M()` when the return type is `T`
- dynamic conversion or cast to `T` when the dynamic might be null
- explicit conversion to `T`
- `e as T` when there is not an implicit conversion from the type of `e` to `T`
- a call to a method like `FirstOrDefault()` that is annotated with `[MaybeNull] (not yet implemented)

We remove the hidden diagnostics previously computed by the NullableWalker.

We add debugger display support for a number of types used by the NullableWalker.  The display for `NullableWalker` summarizes the computed nullability of variables in a nice compact form.

We remove support for definite assignment in the NullableWalker.  Some scenarios involving the use of not-definitely-assigned variables may cause cascaded diagnostics.  We might remove them in the future by initializing all vaiables to the `NotNull` state when they enter scope.

We overhaul and simplify the inplementation of conversions, the null-conditional operator, and result inference for lifted operators.

We simplify the Meet and Join operations so that they form a lattice on both the NullableAnnotation and NullableFlowState.

Catch variables are now initialized to a non-null state on entry to the catch block.

In unreachable code, every expression produces a non-null rvalue.  An erroneous expression produces a non-null rvalue (to suppress cascaded diagnostics).

The bootstrap builds of the compiler today are using the default trace
listener which presents a dialog. That means when a `Debug.Assert` call
fires we end up hanging the build in Azure.

The intent was always for the bootstrap builds to use the
`ExitingTraceListener`. This way they exit with a crash and call stack
that allows the compiler team to diagnose the failure.

The behavior of `Debug.Assert` showing a dialog is the most likely
explanation for our current random hangs in the determinism leg. That is
the only place we still use a `DEBUG + BOOTSTRAP` build. The symptoms
line up. If that's the case this will start showing us the stack trace
of the assert.

* Document ref enumerator disposal compat break
* Add a ref struct disposal test:
- Check that we don't call Dispose on a ref struct enumerator in language versions lower than 8.0
- Add an execution test to check end to end

The name for the named pipe used between MSBuild and VBCSCompiler is
generated from a combination of values including the current user name,
specifically `%USERNAME%`. It is possible for this value to have spaces
in it and hence the argument must be quoted when passing it to the
command line of VBCSCompiler instances.

Regression initially introduced: #32257

The name for the named pipe used between MSBuild and VBCSCompiler is
generated from a combination of values including the current user name,
specifically `%USERNAME%`. It is possible for this value to have spaces
in it and hence the argument must be quoted when passing it to the
command line of VBCSCompiler instances.

Regression initially introduced: #32257

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.

Most nullability checking of tuple values should occur during the
nullable walking phase. This is because the test relies on the inference
of the values, not the explicit types in the code. The only time we need
to validate tuple nullability constarints during initial binding is when
we're binding a named type.

- 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".