the JPF internal representation for Java Annotations
AnnotationInfos represent a separate type system. While we could have used normal ClassInfos
(Java annotations are just restricted interfaces with some syntactic sugar), we keep this separate because
ClassInfos would be overkill. Besides, our runtime behavior differs in that we synchronously load
annotation class files when we encounter them during normal ClassInfo construction (i.e. we parse recursively),
whereas a normal JVM only loads them once they are referenced. The reason why we deviate is that
annotations are used more often in tools than via reflection within the SUT, i.e. they most likely will
be read either by JPF or by listeners, so we want them as soon as possible to avoid additional class state.
This also means we do not faithfully model ClassNotFoundExceptions on annotations due to reflection
calls within the SUT, but that seems less important than having them available during ClassInfo construction.
This mostly matters because of default values and inherited class annotations.
Note - AnnotationInfos loaded by the same ClassLoader that do not have explicitly set values are shared
between annotated objects
this records if the associated class file has been loaded. If it isn't resolved yet,
we don't know about default values, hence we need to check before retrieving field values
that have not been explicitly set. Note this is search global and hence does not need to
be state managed since we only check for default values, i.e. there are no side effects.
Loading has to happen with the right ClassLoader though