Specify the private override error caused by a mixin application

[eernstg]

Proposed rules for a mixin related name clash error, cf. dart-lang/sdk#28809 and dart-lang/sdk#45959.

This PR adjusts the language specification section 'Mixin Application' such that it specifies the error which arises when an override relationship arises among two concrete declarations with a private name n in a library L because of a mixin application that occurs outside L.

// Library 'lib.dart'.
class A {
  void _foo() {}  
}

class B {
  void _foo() {}
}

mixin M {
  void _foo() {}
}

mixin MA implements A {
  void _foo() {}
}

// Library 'other.dart'.
import 'lib.dart';

class AB extends A with B {} // Error.
class AM extends A with M {} // Error.
class AMA extends A with MA {} // Error.

Note that it is an error in all cases where the mixin application outside lib.dart creates an override relationship for a member with a private name (for instance, such that A._foo is overridden by MA._foo), even in the cases where the given members are already associated with each other by declarations (e.g., MA._foo is connected to A._foo by implements A, but it is still an error to have A with MA in other.dart).

[lrhn]

Did we agree on it needing to be concrete?

[eernstg]

No, this PR awaits the discussion in the language team: Do we want to support these mixin applications in all the cases where it does not give rise to an override, or do we want to raise an error on all clashes (abstract or concrete, that doesn't matter)?

My preferred approach is the former, because I don't want to eliminate expressive power gratuitously.

However, we certainly need to raise an error when there is an override because of an implicitly induced implementation (say, a stub that checks the type of an actual argument and calls super.sameMember).

This means that the text in this PR needs to be updated, but it should be updated in two different ways if we choose the former respectively the latter approach.

[eernstg]

Cf. the decision at the language meeting yesterday, the PR has now been updated to make it an error when the private collision as created by a mixin application, no matter what kind of clash we have (concrete/concrete, concrete/abstract, concrete/stub, abstract/abstract, it's always an error).

[eernstg]

PTAL, the spec change has been updated to reflect the decision at the language meeting yesterday: All clashes are conflicts, even abstract/abstract.

[eernstg]

The commentary about the private collisions was extended to motivate the error for some abstract-on-concrete cases.