Impact: a refinement in a superclass's spec is not used for hints on a subclass receiver when some class in between declares an overload with the same name and number of parameters. The error has no hints at all, although the fix is a single call the spec describes.

Minimal reproducer

// Refs.java
@StateSet({"noPopup", "hasPopup"})
@ExternalRefinementsFor("java.awt.Component")
public interface Refs {
    @StateRefinement(to = "hasPopup(this)")
    void add(java.awt.PopupMenu popup);
}

@ExternalRefinementsFor("java.awt.Frame")
interface FrameRefs {
    @StateRefinement(to = "noPopup(this)")
    void Frame(String title);

    @StateRefinement(from = "hasPopup(this)")
    void setState(int state);
}

// Use.java
public class Use {
    static void hint() {
        Frame f = new Frame("x");
        f.setState(0);           // error, no hints
    }

    static void followHint() {
        Frame f = new Frame("x");
        f.add(new PopupMenu());
        f.setState(0);           // verifies
    }
}

Actual (main @ 19991d3, and with the PR for #456): found noPopup(f) but expected hasPopup(f) with no hints. Main has no hints because the machine is only built from Frame's own spec. With #456, the state machine for a Frame receiver includes inherited refinements, but only when the nearest type that declares a method with that name and number of parameters is the type the refinement is written for. Container declares add(Component), which also has one parameter, so Component.add(PopupMenu) is left out (the machine is marked incomplete, so the hints stay sound).

Expected:

Hints:
  - Call f.add(PopupMenu) before this call to move f from noPopup to hasPopup

To get there, StateMachineBuilder should match a declaring method by its erased parameter types, and fall back to the number of parameters only when the types cannot be compared (e.g. type variables).

Depends on the PR for #456.