We weren't ensuring the the tuple elements had top-level nullability
if we inferred the pattern was itself using nullable.

This clarifies why we are stripping the nullability, and replaces it
with the "not null" instead of "oblivious" which generates to the same
code but is a bit more correct if something else tried to operate on
the type symbol.

In the deepest of ironies, the extension methods we had to wrap
top-level nullability was implicitly hiding a potential null reference.
Removing the extension methods is now flagging this, so this fixes it
up. The handling isn't ideal: if we don't have a Task<T> we won't
necessarily wrap, but that's not something really worth going out of
our way to support -- most code doesn't.

The compiler merged support for top-level symbol nullability in
https://github.com/dotnet/roslyn/pull/39498, so we can now delete our
own wrappers that were performing the same thing. This is a mostly
mechanical change.

For places where we were calling LookupSymbols or ClassifyConversion,
those places previously called .WithoutNullability() since the compiler
API would have thrown if we gave it our wrappers, but the APIs had
otherwise no way to pass top-leve nullability. That was an accepted
oversight at the time, and the belief is passing in the full symbol
will generally be more correct.

This wasn't necessary when we had wrapped symbols, since it was the
wrapper that had the annotation. Now that we are removing wrappers
we need to implement it directly.

Our constructed type symbol was holding onto an abstract type symbol;
this allowed a constructed type to be created atop another constructed
type, which would form a chain. That isn't really necessary, and doesn't
match the usual mental models. This switches to holding onto a stronger
type, and then updates the Construct methods to go back to the prior
ConstructedFrom in order to avoid creating a chain.

- Microsoft.DotNet.Arcade.Sdk - 5.0.0-beta.19601.1

* Update list of C# Next features and reviewers

* Add pattern matching features

- Microsoft.DotNet.Arcade.Sdk - 5.0.0-beta.19580.1

* Update dependencies from https://github.com/dotnet/arcade build 20191128.1

- Microsoft.DotNet.Arcade.Sdk - 5.0.0-beta.19578.1

* Update dependencies from https://github.com/dotnet/arcade build 20191129.1

- Microsoft.DotNet.Arcade.Sdk - 5.0.0-beta.19579.1

- Microsoft.DotNet.Arcade.Sdk - 5.0.0-beta.19577.4

Add code action to extract local functions

Fix for configuring code style for "infer member names in anonymous types" persists the wrong setting 

- Microsoft.DotNet.Arcade.Sdk - 5.0.0-beta.19576.2

Simplify how we compute and store the location we use to persist the sqlite storage cache.

Co-Authored-By: NSam Harwell <sam@tunnelvisionlabs.com>

Move LiveShare off of the deprecated constructors and project shims

- Microsoft.DotNet.Arcade.Sdk - 5.0.0-beta.19575.7

Our package load does a bunch of specific things like setting up static
state and ensuring we have certain components loaded on the UI thread.
The InitOptionsAsync was doing just a small part of that, and missing
other things that had undefined behavior. This just loads the package
which is a bit heavy handed but at least ensures we won't have
differing behavior which is probably for the best until we delete all of
this.

Live Share was still using a bunch of deprecated shims which in some
cases were only existing to support this code. Delete it all and move
onto direct uses of the Workspaces API.

There appears to be a memory leak in the existing code: it doesn't
appear the projects that were created for Razor contained documents were
ever removed from the workspace. This maintains that leak since it's not
obvious how to fix it, but at least the leak is more obvious now.