Extracts out the changes to core Workspace changes from https://github.com/dotnet/roslyn/pull/41363.

TypeInfo explicitly returns a Type or ConvertedType, the top-level
nullability of which is the flow state nullability. It also explicitly
gives you annotated nullability prior to us including nullability
in with types. This PR removes the explicit use of the annotated
nullability when it doesn't matter, namely when the thing you're
calling GetTypeInfo is already a TypeSyntax so the 'flow state' was
never really a flow state to begin with.

On a TypeInfo, the ConvertedType and Type properties are already the
flow-nullability form, so we don't need to do anything special anymore.

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

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.

When we're inferring around error types, we won't add ?s for now because
they're more likely to be classes than structs, and we don't know yet
exactly where the resulting syntax will get put.

https://github.com/dotnet/roslyn/issues/37852 will track a fancier fix
to this.

If we have inferred the thing to the left of a ?? is a reference type,
we can annotate it; we didn't update that yet in the type inferrer
though until we had the ability to properly remove the ? if the
user wasn't in the right context. The parent commit of this commit fixes
that so we can fix this now.

The type inferrer does method type inferrence if we know what the
return type of the method should be. This triggered if the method was
handled an argument which it could then chase up and find the
InvocationExpressionSyntax. Unfortunately if you are inferring and
don't have an argument you still want to be able to infer the type
of the argument if there was one there, but there's no ArgumentSyntax
to work from. Thus, it's easier to just directly pass the
InvocationExpressionSyntax and avoid the tree walk; looking through
the callers of InferTypeInArgument there's only one place where
it could potentially find an InvocationExpressionSyntax, and that one
place is the place I updated the call site on.

Now that https://github.com/dotnet/roslyn/issues/36047 is fixed, unskip
type inferrer tests.

Also add extension methods to help with nullability

I added a test to ensure the inferrer no longer crashes, but
https://github.com/dotnet/roslyn/issues/36046 still blocks the ability
for it to actually pass. The test is then added skipped until that
works.

This catches places we're calling Construct() or
ClassifyConversion().

This enables basic support for applying top-level nullability to
parameters and the return types when generating methods.

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

* Rename "deconstruct pattern" to "positional pattern" in the APIs.
Fixes #32291

* Permit a trailing commas in two places
- Permit a trailing comma after the last arm of a switch expression
- Permit a trailing comma after the last subpattern of a property pattern clause
Fixes #32292

Fixes #27647