Add and apply nullable attributes

[stephentoub]

This updates Corelib to use the nullable attributes proposed in https://github.com/dotnet/csharplang/blob/master/meetings/2019/LDM-2019-05-15.md and https://github.com/dotnet/corefx/issues/37826.

• This is a draft until the attributes are approved; I guessed at what we'd want the shape of the attributes to look like, including the AttributeUsageAttributes, so those are likely to be tweaked.
• We may also want to wait to merge this until most of the attributes are respected by the C# compiler; otherwise, there's a good chance updating the compiler subsequently will result in a bunch of warnings due to this PR being done without any automated validation.
• Once this is merged, we'll want to make similar changes in corefx for the ~180 types nullable-enabled there as part of completing the ref assemblies that touch corelib.
• Most of the attributes I added are in places unambiguous in what was needed. A few, in particular on fields, are debatable, and we may want to tweak those.

It also removes ~300 TODO-NULLABLE comments for things that we expect will persist for at least .NET Core 3.0 / C# 8:

• We were using the comments to track the case of methods like Register(Action<object?>, object?), where we need to allow nulls, but if a lambda is used for the first argument and if we had a way to say that the argument to the lambda would be non-null if the object state were non-null, then the compiler could avoid null warnings on the lambda argument. In the future, in theory [NotNullIfNotNull("state")] could be used if it could be applied to generic type arguments.
• We were using the comments to track the case where out ArraySegment was used and then the .Array was producing potential null warnings. We will not have a way to express the constraint that the .Array in this case will be non-null.
• We were using the comments to track the case where a method took a Boolean like bool throwOnFailure, in which case the caller would know that the nullable return value would be non-null if that argument was set to true. We will not have a way to express that constraint.
• Due to time constraints, we expect these nullable attributes to affect consumption of methods that use them but for them to not work to suppress warnings inside of the methods in which they're applied. As such, I've removed comments tracking such things.
• We were using the comments to track cases that would benefit from the compiler tracking Boolean relationships and using that for inference (e.g. Debug.Assert(a is null || b is null)). That's not going to happen for the foreseeable future, so I've removed such comments.
• We were using the comments to track cases where we could potentially improve the signature of explicit interface implementations, e.g. removing a ? from a return value, but as these are explicit implementations, there's no benefit to being more accurate, and I simply cleaned up the comments.
• There were a few cases where comments were tracking things already fixed.
• There were a few cases where comments were tracking potential null dereferences in niche corner cases, generally on exceptional paths. Since they're not perf critical and the fixes were trivial, I fixed them and removed the comments.

I also cleaned up the remaining ~400 TODO-NULLABLE comments to make them consistent and searchable. What currently remains:

221: "Remove ! when [DoesNotReturn] respected"
 68: "Remove ! when nullable attributes are respected"
 29: "Indexer nullability tracked (https://github.com/dotnet/roslyn/issues/34644)"
 28: "default(T) == null warning (https://github.com/dotnet/roslyn/issues/34757)"
 25: "Remove ! when compiler specially-recognizes CompareExchange for nullability"
 11: "Avoid nulling out in Dispose"
  9: "Covariant return types (https://github.com/dotnet/roslyn/issues/23268)"
  8: "Remove warning disable when nullable attributes are respected"
  7: "Covariant interface arguments (https://github.com/dotnet/roslyn/issues/35817)"
  5: "Pass non-null string? to string ref (https://github.com/dotnet/roslyn/issues/34874)"
  2: "Covariant parameter types (https://github.com/dotnet/roslyn/issues/30958)"
  1: "Manually-implemented property (https://github.com/dotnet/roslyn/issues/34792)"
  1: "Null conditional access (https://github.com/dotnet/roslyn/issues/34942)"
  1: "Deconstruct KeyValuePair (https://github.com/dotnet/roslyn/issues/35131)"

Some of these Roslyn issues have been fixed but are still showing up in Corelib, likely because we've not yet consumed the fixes.

A few open issues:

• For properties I put the attributes on the accessors. Should we prefer to put them on the properties instead?
• We could enforce that in some cases by actually removing the Property value from the AttributeUsage. Should we?

cc: @dotnet/nullablefc, @jkotas, @MadsTorgersen, @jaredpar, @jcouv, @cston

[stephentoub]

@MadsTorgersen, @jaredpar, @terrajobst, updated based on yesterday's review. It'd be great if you could help confirm that NullableAttributes.cs (https://github.com/dotnet/coreclr/pull/24679/files#diff-dae9d3bef16ae4885cceab78315f8619) is what we agreed to or not.

[stephentoub]

@safern, this is ready for review.

[safern]

@safern, this is ready for review.

Looking.

[safern]

Left some comments, questions. I spotted one missing attribute in Version.TryParse override. Overall LGTM.

[stephentoub]

Thanks for the review, Santi!