Should combined member signature computation be defined WRT the current library?

This issue is an attempt to split out one of several overlapping issues relative to [this issue](https://github.com/dart-lang/language/issues/2020).

In discussion in the last language team meeting, I believe the claim was made that the following code is, per the spec, valid code which should be accepted:

```dart
// lib.dart
abstract class A {
void _m(String x);
int get _x => 3;
void _n([int x]);
}

abstract class B {
void _m(int x);
void _x() {}
void _n({int x});
}
```

```dart
// main.dart
import "lib.dart";

abstract class C implements A, B {}

void main() {}
```

I believe that the reason for this is that the definition of combined member signature (section 11.2.2) is done with respect to a library `L`, thereby filtering out inaccessible members from consideration when requiring that there exist a member signature in one or more of the super-interfaces which is a subtype of all of the others.

@eernstg is this a correct summary of the position WRT to the current specification, or have I missed other relevant bits?

Note that none of our implementations currently accept this program: the definition of class `C` causes errors to be emitted for all three members.

Note that there is no concrete member which can implement `_n`, nor `_x`. For `_m` there is a valid signature which implements both, but we do not specify any way of computing this, and neither declaration of `_m` is a subtype of the other.

It seems to me that allowing this program is very contrary to the notion of combined member signature. There is no valid combined signature which can be computed. Practically speaking, this becomes an issue for the question of generating a noSuchMethod forward for these members: what is the signature (what even is the calling convention?) for the generated forwarder?

I believe that we should specify this program to be an error, and impose the combined member signature requirements to all members, accessible or not. Thoughts on this?

cc @eernstg @munificent @lrhn @jakemac53 @natebosch @chloestefantsova @johnniwinther @scheglov

Start with section 11.2.2 of the Dart specification and compare its library-relative combined member signature rules with the lib.dart and main.dart examples. Review the discussion and implementation behavior described in the issue; the work is done when the specification clearly resolves inaccessible members, incompatible signatures, and the resulting noSuchMethod forwarder behavior.

Written by the indexing model from the issue text.