Clarify interactions between settings for generated code, restrictive annotations, etc.

Historically, NullAway has had settings for "annotated" vs "unannotated" packages and classes. Annotated code is assumed to be annotated according to NullAway's conventions. For unannotated code, we make no such assumption, and further, by default we completely ignore any annotations present in that code. This default can be changed via the AcknowledgeRestrictiveAnnotations setting; when provided, this setting causes @Nullable annotations on return types and @NonNull annotations on parameter types to be acknowledged even within unannotated code.

NullAway also has a setting TreatGeneratedAsUnannotated which causes all code within a @Generated annotation (or any custom generated code annotation) to be treated as unannotated. Crucially (and non-obviously), if both TreatGeneratedAsUnannotated and AcknowledgeRestrictiveAnnotations are passed, restrictive annotations in generated code are still not acknowledged. Our TreatGeneratedAsUnannotated setting is rather coarse, and in trying to make it more flexible, I ran into this subtle interaction that I hadn't recalled.

Also, NullAway now supports @NullMarked and @NullUnmarked annotations. @NullMarked is equivalent to "annotated" (I think), whereas @NullUnmarked corresponds to "unannotated" with the AcknowledgeRestrictiveAnnotations setting enabled. There is no standard null-markedness setting that corresponds to our default "unannotated" config, where all annotations are ignored.

So what is the point of this issue?

• At the least, we could and should document the above better.
• I wonder if AcknowledgeRestrictiveAnnotations should be on by default, with a setting to disable it? This way, "unannotated" and @NullUnmarked would be equivalent out of the box, modulo generated code.
• I'm not a fan of the subtle interaction between AcknowledgeRestrictiveAnnotations and TreatGeneratedAsUnannotated; maybe we can do better?

Start with the linked Configuration wiki sections for AcknowledgeRestrictiveAnnotations and TreatGeneratedAsUnannotated, then compare them with the descriptions of @NullMarked and @NullUnmarked. Document the current interactions and defaults, including generated code behavior; the issue is done when the configuration combinations and their differences are unambiguous.