Rename from IncludeNonNullableReferenceTypeModifier to IncludeNotNullableReferenceTypeModifier (#41332)

Closes #41304

This API has always accepted null as a shortcut for an empty array, so
this annotates it accordingly.

Had to clean up a few nullable annotations now that we are compiling
agaist `netcoreapp3.1` and hence get the full value of the framework
annotations.

This is also problematic though because there are now two places where
the compiler can see nullable attributes that are directly used by the
developer. For example `NotNullWhenAttribute`. This is both defined in
our assemblies for non-netcoreapp target frameworks and provided by the
SDK when targeting `netcoreapp3.1`.

This causes a problem for assemblies which have the following
characteristics:

1. Target `netcoreapp3.1`
1. Reference an assembly targeting `netstandard2.0` which uses our
nullable attributes definition
1. Has IVT into (2) above

These properties essentially define all of our unit test assemblies. In
that environment it's not possible to use nullable attributes in code
because the compiler can't disambiguate which definition of
`NotNullWhenAttribute` to use. This meant I had to temporarily remove a
few attributes until we can complete #40766.

Decided to remove the property based approach to specifying a target
framework to just specifying `netcoreapp3.1` directly. The reason for
this is the following:

The advantage of the property is it makes it "easy" to change to a new
target framework in the future. That benefit is actually pretty minimal.
A simple find and replace operation is **extremely** effective in our
code base (it's less key strokes than this message). Hence the benefit
is minimal.

The downside of the property is that our code doesn't look like customer
code. Or rather it diverges from the practices that we publish. In
general I prefer to keep our code as standard as possible unless there
is a good reason to deviate. There just doesn't seem to be one here.

Change Roslyn to target netcoreapp3.1 when building .NET Core assets.

Previously the code targetted a mix of netcoreapp2.1 and netcoreapp3.0.
The mix is due to default interfaces only being supported on
netcoreapp3.0 and hence our testing needed to use that. Yet at the same
time we were required to ship the compiler in SDKS that targetted
netcoreapp2.1. Now we can universally target netcoreapp3.1.

* Move "is telemetry allowed" flag to DiagnosticAnalyzerInfoCache

* Clean up DiagnosticService

* Fixes

* Remove analyzer exception telemetry reporting.

* Remove reporting analyzer exceptions from SupportedDiagnostics.

The diagnostics will be reported when the compiler runs the analyzer on the compilation.

* Remove unused parameter

* Clean up analyzer telemetry reporting.

* Test fixes

* Feedback

Addresses 3200MB allocations while analyzing Roslyn.sln.

Addresses 950MB allocations while analyzing Roslyn.sln.

Addresses 950MB allocations while analyzing Roslyn.sln.

Addresses 2400MB allocations while analyzing Roslyn.sln.

fix for language code capitalization

Addresses 680MB allocations analyzing Roslyn.sln.

The `SyntaxNodeOrToken` type had four states:

1. It's a `SyntaxNode`
1. It's a `SyntaxToken`
1. It's `default(SyntaxNodeOrToken)`
1. It returns `true` for `IsNode` but `AsNode` returns `null`

The fourth state appears to be an accident of implementation. This
change removes that state. The one place in the code where this appeared
to be an issue is in the implicit conversion from `SyntaxNode?` to
`SyntaxNodeOrToken`. In all places where this was used and the value was
potentially `null` the caller only used `GetLocation` on the result.
Hence the fix is simply to change that API to return `default` instead
of the fourth state in the case of `null`