Need for self-reference in dependent type annotations

The Nullness Checker rejects the following assignments:

    public void copy1(
            HashMap<String, List<@KeyFor("#1") String>> a,
            HashMap<String, List<@KeyFor("#2") String>> b) {
        a = b;  // incorrectly rejected
    }

    public void copy2() {
        HashMap<String, List<@KeyFor("b") String>> b = null;  // OK
        HashMap<String, List<@KeyFor("a") String>> a = b;     // incorrectly rejected
    }

There are numerous other examples in file SelfDependentType.java, which also illustrates other bugs.

To make this type-check seems to require either significantly more sophisticated dependent type standardization at assignments, or a <self> type like that supported by the Lock Checker.

Start by reading SelfDependentType.java and the two assignment examples in the issue, then trace how the Nullness Checker standardizes dependent type annotations during assignment checking. Compare the failing cases with the self-reference support mentioned for the Lock Checker. Done means the documented self-referential assignments type-check without regressing the other examples in SelfDependentType.java.