Permit stub files to specify non-existent overriding methods

Sometimes, a method defined in a superclass behaves differently for a subclass, even though the subclass inherits the method (the subclass does not override or redefine the method). Here is a trivial example:

class Super {
  int a() { return Random.nextInt(); }

  int b() { return this.a(); }
}

class Sub extends Super {
  @NonNegative int a() { return Random.nextInt(Integer.MAX_VALUE); }
}

The return type of Sub.b is @NonNegative int, but there is no way to specify this fact.

As a more realistic example, consider javax.lang.model.element.Name.
It should be specified by

interface Name {
    @PolySignature String toString(@PolySignature Name this);
}

but Name does not define an override of toString.

Here are some more words to make this issue more discoverable by searching: override, overridden, inherit, inherited.

Start by tracing how stub files represent methods and inherited members, using the Super/Sub example and javax.lang.model.element.Name as cases to support. Determine how a stub can describe an inherited method without declaring a real override. Done means stub files can express the differing contract for inherited methods and the relevant checker behavior is covered.