Closes #30171.
Closes #29838.

Preserve non-nullable state of a value that is going through explicit conversion to an unconstrained type parameter.

Handle unconstrained type parameters in conditional operator.

Explicitly pass NullableAnnotation value to TypeSymbolWithAnnotations.Create method.

Handle unconstrained type parameters in conditional access.

Handle unconstrained type parameters in “As” conversion operator.

Remove obsolete APIs from TypeSymbolWithAnnotations

Closes #30050.
Closes #30051.

 Adjust the way nullable annotations are represented in metadata.

Closes #30075.
Closes #30065.
Closes #29594.
Closes #29683
Closes #29662

Add tests to demonstrate that they are associative and commutative.
Add (skipped) tests to demonstrate that we have inconsistent meet and join functions.
    We will have to decide how to handle the differences.
I have not yet extracted the NullableState operations from ConversionsBase
    (e.g. testing if one NullableState is higher or lower than another in the lattice)
Also removed some inoperative code in MethodTypeInference

Remove NonNullTypes context and other unnecessary information stored in TypeSymbolWithAnnotations. (#30913)

Remove NonNullTypes context and other unnecessary information stored in TypeSymbolWithAnnotations.

Fixes #30845.

Explicitly handle nullability analysis for unconstraint type parameters.

Related to #29981, #29993

Fixes https://github.com/dotnet/roslyn/issues/30966
Implements the spec change described in https://github.com/dotnet/roslyn/pull/30670
See also https://github.com/dotnet/roslyn/issues/30989

* Expression tree reflike checks WIP

* Move test from emit to semantics

* Fix ExpressionTreeRefLikeWalker

* Fix label indent

* Add more tests

* Move ExpressionTreeRefLikeWalker logic to DiagnosticsPass

* Resolve TODOs in IsExpressionTree

* Ignore BoundConversion when checking for ref structs in expression trees

* Comment on the purpose of `!(node is BoundConversion)`

* Add ErrorCode.ERR_ExpressionTreeCantContainRefStruct

* Use new error code in DiagnosticsPass

* Update tests

* Add TypedReference tests

* Replace IsByRefLikeType check with IsRestrictedType() check

* Simplify VisitLambda

* Add new diagnostics to ArglistTests.ExpressionTreeTest

* Add test for tuple operator increment

* Ignore tuple names when comparing return types to parameter types in increment/decrement operators

* Add test for tuple identity conversion operator

* Ignore tuple names when comparing conversion operator parameter and return types

* Add test for tuple conversion to base type

* Ignore tuple names when determining whether parameter or return type contains a conversion operator

* Add test for tuple binary operator

* Filter out type conflict warnings

* Check for restricted return types on local functions

* Add test for restricted local function returns

* Add test for local function ref parameters of restricted types

* Add test to demonstrate that local functions can return Span<T>

Fixes #28684.
Fixes #29837.
Fixes #30001.
Fixes #30052.
Fixes #30054.
Fixes #30068.
Fixes #30072.
Fixes #30178.
Fixes #30220.

This type, and it's children, had the same race condition around
attributes that `SourceEventSymbol` did. After some thought I decided to
move this code back into `SourceCompletionState` with a new name to make
it clear the completion is around attributes only.

This is a follow up to #29807

There is a race condition around the setting of
`CompletionPart.Attributes` in `SourceEventSymbol`. This can be exposed
when the following execution pattern occurs:

- Thread1: Calls `GetAttributesBag` and pauses execution on the line `
`DeclaringCompilation.SymbolDeclaredEvent(this)`
- Thread2: Calls `ForceComplete` which will unconditionally call
`state.NotePartComplete(CompletionPart.Attributes)`
- Thread1: Resumes and hits an assert because `NotePartComplete` returns
`false`.

The root problem here is the unconditional call of `NotePartComplete`
inside of `ForceComplete`. The pattern in all of our other symbols for
`ForceComplete` is the following:

- Call `GetAttributes`
- Call `SpinWaitComplete(CompletionPart.Attributes, cancellationToken)`

This ensures that `NotePartComplete` is executed on the thread which
actually completes the loading of attributes.

As a part of fixing this I looked through all other uses of
`NotePartComplete(CompletionPart.Attributes)` to ensure they didn't have
this problem. Checked VB as well and it doesn't seem to have this issue.

Struggled to find a good way to test this as it's a race condition.
Given the high number of bugs we've recently filed on this assert I'm
confident we have the indirect coverage in our suites.

closes #28954