[Nullable Reference Types] Specify nullable flow analysis lattice

[BillWagner]

Specify the general rules for static flow analysis of nullable states. Namely, the standard should specify:

• The possible null-state of a variable or expression (not-null or maybe-null)
• The initial nullable state of a variable, based on the nullable context and its declared type
• Some general rules about flow analysis and diagnostics.

That final bullet is fraught with risk. We don't want to constrain any future compiler innovations that improve static analysis. However, we need to paint some general view of the diagnostics to provide useful information both for compiler writers and C# programmers.

[BillWagner]

See https://github.com/dotnet/csharpstandard/pull/1124/files#r1632781297 for more context here.

Depending on the resolution of that conversation, this PR should clarify how property accessors are handled. The result of invoking the set accessor, or the null-state of the value returned by a get accessor impacts the null-state of subsequent get accessors.

Stated non-normatively, the null state of a property is treated as though it is a variable.

That is not true for method invocations: Their result is not considered consistent between invocations.

[BillWagner]

From discussion during the 7/10 meeting:

We may to have three state:

• not-null
• maybe-null
• oblivious

The existence of the oblivious state comes from any declaration when the annotation flag is disabled

[BillWagner]

We should discuss this issue and #1092 in our next meeting.

Does any of the information on the static analysis belong in the standard?

If so, what?

[BillWagner]

While working on the PR for generic type constraints, I looked again at #700.

That contains normative language on requirements to initialize static and instance fields either in initializers or all constructors. Should we add either conditionally normative or informative language regarding those rules?