The old annotation API was pretty inconsistent with all other SootUp APIs
because several methods expected a JavaView object. Examples:

- JavaSootClass.getAnnotations(@nonnull Optional<JavaView> view)
- JavaSootMethod.getAnnotations(@nonnull Optional<JavaView> view)

For instance, in JavaSootClass.getAnnotations the JavaView is used to
- retrieve the superclass' JavaSootClass in order to take inherited
  annotations into account
- retrieve potential default values from an AnnotationType

While this might come handy, this "conflicts" with existing SootUp APIs.
For instance, JavaSootClass.getMethods() only returns the methods that are
defined in the corresponding class and does not take methods from the
superclass or interfaces into account. These methods have to be manually
retrieved by first retrieving the superclass' type from the JavaSootClass,
then the JavaSootClass that corresponds to the superclass' type is queried
from the JavaView, and, finally, the getMethods() method is called on that
JavaSootClass instance etc.
Hence, we make the annotation API consistent with the other existing APIs.
Unfortunately, this breaks the existing API.

(Incompatible) API changes:

- java.core.AnnotationUsage:
  * getAnnotation() returns a ClassType instead of an AnnotationType
  * getValuesWithDefaults() is removed without any replacement. For now,
    the merging of the actual values with the default values has to be done
    manually.

- java.core.JavaAnnotationSootClass:
  * getDefaultValues() is introduced in order to retrieve the default values
    that are defined in the corresponding annotation interface.

- java.core.JavaIdentifierFactory:
  * getAnnotationType(...) is removed without any replacement.

- java.core.JavaPackageName:
  * getAnnotations(...) and a constructor that takes a list of
    AnnotationUsage instances are removed without any replacement (they are
    unused within SootUp's codebase). The potential annotations can be
    retrieved by querying the corresponding package-info file from the
    JavaView (for instance, see the newly introduced
    PackageAnnotationTest.testPackageAnnotation test).

- java.core.JavaSootClass:
  * getAnnotations(@nonnull Optional<JavaView> view) is replaced by
    getAnnotations(), which does *not* take potential inherited annotations
    or default values into account.

- java.core.JavaSootMethod, java.core.JavaSootField:
  * as in the JavaSootClass case above.

- java.core.types.AnnotationType:
  This class is removed. An annotation interface type is represented by a
  (Java-) ClassType.

- bytecode.frontend.AsmUtil.createAnnotationUsage(List<AnnotationNode> invisibleParameterAnnotation):
  If the annotationValue is an instance of AnnotationNode, the old code stored
  a list, which contains a single AnnotationUsage instance, in the paramMap.
  This is counterintuitive because this does not reflect the "structure" of
  the element's type in the annotation interface definition. Hence, the new
  code stores the AnnotationUsage instance directly in the paramMap.
  The new behavior is documented in the
  AnnotationUsageTest.testAnnotationWithNestedAnnotationDefaultValues test.
  The existing NestedAnnotationTest.testNestedAnnotation is adjusted
  accordingly.

- bytecode.frontend.AsmMethodSource.resolveAnnotationsInDefaultValue(Object a):
  If the passed object "a" is an instance of AnnotationNode, the old code
  transformed it into a list containing a single AnnotationUsage instance.
  As above, this is counterintuitive because it does not reflect the element's
  type structure in the annotation interface definition. Hence, the new code
  just returns the AnnotationUsage itself without wrapping it in a list.
  The new behavior is documented in the
  AnnotationUsageTest.testContainerAnnotationDefaultValues test.

Note: Some of the reformatting noise in JavaSootMethod was caused by running
"mvn fmt:format"...