Degrade gracefully in InitializationChecker when @PolyInitialized or @NotOnlyInitialized are missing from classpath

[wmdietl]

Problem

When running EISOP's NullnessChecker (or any checker using InitializationChecker) in a project where the compilation classpath resolves org.checkerframework:checker-qual from upstream typetools rather than EISOP's fork (for instance, when brought in transitively by a dependency), compilation aborts immediately during type factory initialization:

error: AnnotationBuilder: fromClass can't load class org.checkerframework.checker.initialization.qual.PolyInitialized
  Is the class in checker-qual.jar?

Cause

In InitializationParentAnnotatedTypeFactory:

NOT_ONLY_INITIALIZED = AnnotationBuilder.fromClass(elements, NotOnlyInitialized.class);
POLY_INITIALIZED = AnnotationBuilder.fromClass(elements, PolyInitialized.class);

Upstream typetools checker-qual contains @Initialized, @UnderInitialization, @UnknownInitialization, and @FBCBottom, but lacks the EISOP-specific annotations @PolyInitialized (added in #494) and @NotOnlyInitialized. Because AnnotationBuilder.fromClass throws a compiler error when elements.getTypeElement(...) returns null, the checker cannot initialize.

Proposed Solution

Follow a graceful degradation pattern similar to #1906:

1. Safely check if PolyInitialized.class and NotOnlyInitialized.class exist on the compilation classpath before building their AnnotationMirrors.
2. If missing, emit an informative diagnostic NOTE once per run (e.g. informing the user that @PolyInitialized and @NotOnlyInitialized are unavailable without EISOP's checker-qual) and operate without those qualifier features.
3. This will allow NullnessChecker to seamlessly type-check projects using upstream typetools checker-qual on their compilation classpath.