Clarify static checks on superinvocations in mixins: not checked at mixin application, only at run time

[eernstg]

Cf. dart-lang/sdk#35111:

The specification should make it explicit that there is no type check of the bodies of mixin methods at mixin applications (in the example in the issue: the invocation of super.bar in M.test is not checked against the member signature of bar in the actual superclass B during the static analysis of MA).

In other words, we're checking once and for all that super.bar(3.14) is OK according to the member signature A.bar, and the fact that we're calling a member with a different signature in the class MA (and the call is not type correct) is only detected at run time.

[lrhn]

Mixin super-invocations have two checks:

• That the super-invocation itself is valid against the combined on-interface.
• At each mixin application, that the superclass provides a valid implementation of each member of the on-interface which is super-invoked.

By "valid" we define that it's a valid override of the member signature of the combined on-interface.
(It's not enough to be non-abstract, because the superclass could be abstract and still have a concrete implementation of the member, which only satisfies a superinterface.)

The only thing we don't check is that the implementation isn't using covariant, and is therefore not actually providing the service we intend it to.
We could add such a check, saying that the superclass implementation must allow all arguments allowed by the combined on-interface, but that would preclude uses where the covariance is intended and desired. (Maybe the argument to the covariant parameter is provided by the superclass, and is guaranteed to be valid.)

So, current behavior is correct, and that's what we should make sure is specified.

[eernstg]

lt is an anomaly that there is a method invocation in the code which is statically known to be a type violation, and yet we don't report an error at compile time:

class A {
  void m(num n) {}
}

class B implements A {
  void m(covariant int i) {}
}

mixin M on A {
  void callSuper() {
    super.m(3.14);
  }
}

// Statically known: the superinvocation of `m` in `M.callSuper` is not type correct.
class C extends B with M {} // Accepted!

void main() {
  C().callSuper();
}

This is inconsistent because the same type relationship between a call-site and the declaration exists in the following example, and in this case we do report an error:

class A {
  void m(num n) {}
}

class B implements A {
  void m(covariant int i) {}
}

class C extends B { // Error reported at the call which is not type correct.
  void callSuper() {
    super.m(3.14);
  }
}

void main() {
  C().callSuper();
}

We may or may not describe this treatment as 'correct', but I think there's no doubt that we do not want to spend the resources required for checking mixin member bodies at every mixin application.