Introduce abstraction for specifying "class-like" structure

[lrhn]

With extension type, we now have five declarations which can contain static and instance members, some also constructors, and which all have the same rules about naming conflicts in the declaration. We hope, since we've had to either copy the rules for each type, or refer to "just like class" for things that are almost, but not entirely, like a class.

We should extract the shared rules into a single abstraction, so that we can specify the rules precisely (and) once.
Here is a suggested approach.

[eernstg]

Yes, let's have that!

However, I don't think it has to be in terms of class-like declarations in every case. For instance, we have a general rule stating that it is a compile-time error to have two declarations with the same name in the same scope.

We have section Class Member Conflicts specifying various additional conflicts for classes, mixins, and extension declarations. For instance, it is an error if a class C has an instance member with basename n and a static member whose basename is also n. The same error applies when C is an extension, but in the class case the instance member can be declared by a superinterface and in the extension case it can only occur when both members are declared in the body of that extension declaration.

The null safety updates (#2605) include some generalizations. For instance, it uses 'class building type' to describe all the types that are usable as superinterfaces of a class-like declaration. The current language specification keeps repeating a bunch of cases, e.g., here, but the null safety update gets the same effect by specifying that implements ... T ... is an error unless T is a class building type.

I doubt that we can come up with a unified specification of "(nearly) everything which must hold for a class-like declaration", because there tends to be gnarly exceptions every time we introduce a new class-like thing, but I certainly agree that we should try to capture and express the commonalities.

[eernstg]

Looking at the suggested approach, I do recognize that we might be able to extract an extra bit of homogeneity and avoid some redundancy. That would be nice! (As I mentioned, some changes to that effect are already included in the null safety updates.)

We should also keep in mind, though, that every new concept (a new word/phrase, with an associated meaning) is a burden on the reader (especially a reader who does not spend all their time perusing the Dart language specification documents), so it had better have enough information in it to justify learning the word in the first place.

Anyway, one thing we should definitely do is to rename 'Class Member Conflicts' to something else, perhaps just 'Member Conflicts'.