[Checkers] Declarative specification of qualifier hierarchy

[Mahmood Ali]

> I'm not sure I agree with the need for a GraphSubtypeRelation.
I beg to differ. I believe that GraphSubtypeRelation is a necessity,  
or at least that all checkers should re-implement their subtype  
checking, for the following reasons:

1. We don't have any unifying method for the checkers currently.   
Javari is using JavariSubtypeRelation which extends SubtypeRelation  
(which is not subclassed by any other class).  NonNull and Interned  
checkers are using SimpleSubtypeRelation.  IGJ is using its own thing  
within Checker.

2. SimpleSubtypeRelation cannot really be used for other types.  It  
uses some hacks to get around issues related to boxing/unboxing and  
checking against nullability.

3. SubtypeRelation is horribly broken.  It doesn't do anything clever  
about boxing/unboxing and doesn't handle type arguments properly.  For  
example, it doesn't handle the following case (as tested by Javari)

	@Mutable List<@Mutable Date> l1 = null;
	@Mutable List<@ReadOnly Date> l2 = l1;  // should emit error


while l2 is not a subtype of l1.

4. isSubtype sometimes needs to do some more complicated work in  
preperation (unbox boxed type / call asSuperOf on lht), and uses  
different methods for comparing annotations (subtypes for raw type /  
identical for type argument).  It will be extra nice to unify them.

5. It seems to me that we will have other types of annotations  
relations that aren't a subtype relationship as we have worked on.   
Consider the Encrypted/Plaintext type qualifiers that we are  
considering as a case example for the CustomChecker.  They are not  
subtypes of each other, they are indeed in-conflict of each other.  
SubtypeRelationship (and SimpleSubtypeRelationship) shouldn't be able  
to handle this easily.  As a side-note, CustomChecker assumes that the  
negative annotation is a supertype of the positive annotation, which  
is false ("Plaintext/Encrypted", Trusted/Tained, etc).

- Mahmood