- Don't do analysis for speculative attributes
- Manually call TryGetThisParameter, rather than MethodThisParameter which can throw

- Add an entry point to nullable walker for attribute analysis
- Implement analyze attribute in the walker
- Remove the analysis from binder_attributes and call nullable walker instead
- Add extra fields to BoundAttribute that are needed for nullable analysis
- Add some extra test scenarios

Have to disable quiet restore explicitly on local dev machines when
doing a bootstrap build to work around this arcade issue:
https://github.com/dotnet/arcade/issues/2220

* Implement LDM decisions on the behavior of `??` and `??=` operators
Fixes #33743

Bases of Nullable are reference types and thus base methods are called via boxed values which wold NRE on nulls.

Fixes:#33174

```cs
S? x = <expr of Type S>;  // works already
S? x = new Nullable<S>(<expr of Type S>);  // means the same as above and should work the same.
```

Fixes:#32626

* Eliminate unspeakable NullableAnnotation values.
* Dynamic invocations result in an oblivious state
Fixes #33638
* Fix up expected diagnostics
Due to #33924
* Rename NullableAnnotation.Unknown to NullableAnnotation.Oblivious

Fixes #33905

The change to move nullable to a two state solution inadverntently
changed how the CLR inlines a number of method calls. The combination of
not-inlining and over-inlining caused us to have a much larger "frame"
for analyzing a fluent call and exceeded our tolerance levels.

This adjusts the inlining so that we get the same results as before.

closes #33775

See also #28798, #32047, #33879
Closes #29953

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.

* 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

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

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