Clarify extension member resolution

[eernstg]

See #4113 for some background information.

This PR changes the rule about extension applicability such that it is clarified that static members are irrelevant, it is only required that the static type of the receiver does not have an instance member with the same basename as the selector which is potentially an extension member invocation.

There is no implementation effort associated with this specification adjustment, and it is not a breaking change, because the implementations already behavior in the way which is specified with this change.

[lrhn]

Do we have a name for "the set of instance members of a type"? I sometimes use "type interface" or "type member signatures".
It's the signatures of the members that a typed member access/invocation can access on a receiver with that type as static type.
(Because that's the kind of members this text is talking about. Not declarations, not concrete "instance members", just the things that can be accessed on something with that static type.)

[eernstg]

We do use "members of" a library, class, mixin, or enumerated type, "instance members of" a class or extension, "static members of" a class or extension, "a member of" the type void, a super-bounded type, the on-type, "members for" a type, "a member of" an object.

Another branch of this terminology may be better in general: We're quite frequently talking about "the interface of" an interface type, which is considered to be a nominally identified set of member signatures.

So we do certainly talk about the members of a class or class-like entity, explicitly mentioning both of the static and instance kinds. We do also talk about the members of a type (not nearly as many times), again both kinds.

But I think it's fair to say that the elements in the interface of an interface type would be instance members, implicitly or explicitly.

I think we're OK using 'static members of a class' and 'instance members of a class', no problem, and we're pretty much OK using 'static members of an interface type' and 'instance members of an interface type', even though those occurrences should perhaps be modified to talk about the underlying class/mixin/whatever that was used to induce said type.

And I think it's fair to say that the interface of an interface type contains only instance members. We could still include the word 'instance' to double down on the disambiguation.

[lrhn]

Indeed. The issue here is that the on type of an extension may not be an interface type, and yet I want to talk about the interface of it, meaning the set of member signatures that it has. (Which includes the "members of Object", for function types an instance method names call, for record types instance getters for each field, and for extension types, the extension members of the type.

If we could consistently say "the type signature of at type" to mean that set of member signatures, then that could make some things much easier to talk about. (And the type interface/signature of an interface type is the interface type's interface members, unsurprisingly.)

(I've considered "type interface" and "type signature", but I like "signature" better because it matches "member signature", which is itself a useful abstraction over something with a name and a way to use it - getter, setter, or method so far.)

[eernstg]

If we could consistently say "the type signature of at type" to mean that set of member signatures

I've used "the interface of a type" with that intended meaning many times. The specification does say "interface type" in a number of situations, but I don't see a problem with a slightly more forgiving use of this phrase that includes some non-interface types with the Object members as the interface. Record types is a good example, they certainly do have getters named in ways like $1 and $foo, and I don't see why we should special case them in the situation where we just want to talk about the available static information about instance members.