Errors specified for a mixin derived from a class are incomplete

The following change to dartLangSpec.tex took place in 89347169c715d39e5d3e6ae588cd2bdcbb875492:

```
-It is a compile-time error to derive a mixin from a class which explicitly declares a generative constructor.
-It is a compile-time error to derive a mixin from a class which has a superclass other than \code{Object}.
+Mixin application occurs when one or more mixins are mixed into a class declaration via its \WITH{} clause (\ref{mixinApplication}).
+Mixin application may be used to extend a class per section \ref{classes};
+alternatively, a class may be defined as a mixin application as described in the following section.
```

The property of interest here is that, before this change, a class can declare a factory constructor and still allow for deriving a mixin, it is only a generative constructor that causes the error. That rule was discussed in https://github.com/dart-lang/sdk/issues/24767, and the conclusion was that a factory constructor is harmless, so they were allowed.

This reflects the current behavior of our tools (`dart` and `dartanalyzer`, ), where no error is reported for the following:

```dart
class M {
factory M() = M1;
}

class M1 implements M {}
class A {}
class B extends A with M {}

void main() => B();
```

However, the versions since the change mentioned above do not seem to maintain the distinction between factory constructors and generative constructors:

The current version specifies how to derive a mixin from a class declaration [here](https://github.com/dart-lang/language/blob/123ba363819b4be0af80b8a94ef6bd0b36db51ba/specification/dartLangSpec.tex#L4666). It does not state that the derivation is a compile-time error if the resulting mixin declaration has a compile-time error, but it does mention [here](https://github.com/dart-lang/language/blob/123ba363819b4be0af80b8a94ef6bd0b36db51ba/specification/dartLangSpec.tex#L4621) that it is an error if a well-formed mixin cannot be derived when it is applied in a mixin application.

It is not obvious whether the latter rule (which is associated with ``, that is, the kind of class declaration that uses `=`, e.g., `class B = A with M;`) kicks in when we consider a regular class with mixins (e.g., `class C extends A with M {}`), and it would probably be easier to read if we specify the compile-time errors at the location where the derivation of the mixin is specified, and then all usages will be covered.

However, the specification of how to derive a mixin only says that the members of the derived mixin are the instance members of the class (cf. 'The instance members of a class are its instance methods, getters, setters and instance variables'). This implies that we ignore _all_ constructors (so we won't get the distinction between factory and generative constructors, so we won't get the error for generative constructors, not during derivation and not when whe derived mixin is used). This is definitely not what we want.

We should change the specification of how to derive a mixin such that it addresses constructors explicitly, and specifies the error during mixin derivation, and then we can remove the rule that it is an error if the derived mixin is not well-formed when we apply it.

@lrhn, @leafpetersen, @munificent, do you agree?

Start in specification/dartLangSpec.tex at the sections describing mixin derivation and mixin application, including the referenced lines around 4621 and 4666. Trace how regular mixin applications and `= ... with ...` declarations handle constructors and well-formedness. Done means the specification explicitly addresses constructors and reports the intended derivation error consistently, with the redundant application rule removed if appropriate.

Written by the indexing model from the issue text.