Define how variance and late fields in NNBD interact

The NNBD spec adds a notion of `late final` fields which do not need to be initialized in the constructor. This implies the existence of a hidden setter, which in turn implies that there is an interaction with the definition site variance proposal being prototyped by @kallentu . Concretely, in the following code, there is an implied covariance check on the implicit late setter:

```dart
class A {
late final T x;
}

void main() {
A a = A();
a.x = "hello"; // This must throw in the setter
}
```

Consider the sound variant version of this:
```dart
class A {
late final T x;
}

void main() {
A a = A();
a.x = "hello";
}
```

Should this code be rejected based on the implicit setter, which has a hidden contra-variant use of the type variable?

Or should this code be accepted, and be compiled with a runtime check type check on the write?

Note that if we choose to make this a static error, then adding the `covariant` modifier to the `late` field could allow it. Currently we issue an error on `covariant final` fields though, so we would probably want to eliminate that restriction.

```dart
class A {
covariant late final T x;
}

void main() {
A a = A();
a.x = "hello";
}
```

cc @munificent @lrhn @eernstg @kallentu

Start with the NNBD spec and the definition site variance proposal, then work through the `late final` examples in this issue. Determine whether the implicit setter makes the sound variant invalid, requires a runtime check, or should be enabled by `covariant`; done means documenting the chosen interaction and any change to the `covariant final` restriction.

Written by the indexing model from the issue text.