Allow mixins as superclasses. Deprecate using classes as mixins.

[lrhn]

We currently allow some classes to be used as mixins. We always intended to stop doing that, but it's proven hard to make people migrate away from existing mixin-classes because someone might be extending the class as well, and you can't extends Mixin with something declared by a mixin Mixin declaration.

So, to move things along, we should:

• Allow a mixin declaration as a superclass, writing class C extends Mixin ... or class C = Mixin with .... It effectively means using Object with Mixin as the superclass. (A desugaring would be that each mixin Mixin ... declaration gets a synthetic class Mixin$class = Object with Mixin; declaration next to it (fresh, unforgeable name), and all uses of Mixin as superclass instead refers to Mixin$class).
• Immediately deprecate writing extends Mixin [ with ...] and recommend it being written as with Mixin [ , ...] instead. Deprecate class C = Mixin with ... and recommend class C = Object with Mixin, ...; instead.
• Deprecate using a class as a mixin (any mixin application of a class declaration), to encourage authors to migrate their mixin classes to mixin declarations.

This should allow changing all existing mixin-classes to mixin declarations without breaking anyone, and it will encourage people to do so by giving deprecation warnings for any use of a class as a mixin, and any use of a mixin as a class.
The recommended approach is to use mixin for anything which can be mixed in, and only use those with with, not extends.

In a later version of the language, we will then remove the ability to use mixins as superclasses again, along with the ability to use classes as mixins. That will likely not be before Dart 3.0.

[bwilkerson]

Have we considered tooling support that might aid the effort? We could, for example, add a "Convert class to mixin" refactoring that would clean up uses of the class by converting uses in extends clauses to uses in with clauses. Such a tool might even make it unnecessary to add a feature that we intend to immediately deprecate.

But if we do need a more gradual path, when we deprecate the use of mixins in extends clauses we should define a quick fixe (that could be applied by dart fix) to clean up individual occurrences.

[lrhn]

Encouraging people to change class declarations to mixin declarations has been out existing strategy. It has failed spectacularly.

The problem here is that converting a mixin-intended class declarations to a mixin declarations will break client code which uses extends, and it isn't easy to find the offending uses of extends SomeClass when the class declaration is just a class declaration.

So, allowing the declaration to change without breaking existing code, allows us to introduce the information needed to give good hints at the use-sites.