#KT-20131 Fixed

The problem was that `resolveTypeQualifierAnnotation` actually doesn't
guarantee that `typeQualifierAnnotation` is javax.annotation.NonNull
with argument

It could be just any type qualifier (see the test)

For sake of working without jsr305.jar in the classpath `resolveTypeQualifierAnnotation`
may return javax.annotation.CheckForNull (although the latter is nickname itself)

 #KT-19985 Fixed

 #KT-19419 Fixed

 #KT-10942 Fixed

It was only used for type-related nullability/mutability
annotations and it was necessary to remove them
in the descriptor renderer (duplicating their fqnames there).
At the same time they're only needed for types enhancement
where they can be simply restored from type owners' descriptors

The testData changes are more or less correct: this kind of annotations
is bound both to types themselves and their use because of their targets

 #KT-10942 In Progress

DescriptorRenderer to render annotations for all types + separate option to render annotation arguments + use it in IdeDescriptorRenderers

- tests and declarations for checkerframework has been moved,
because they only Java 8 targeted
- tests for eclipse annotations has been just copied,
because there are two jars: one for Java 8 and other for earlier versions

These are different than 'android.support.annotation' in that they are used on the JVM for projects within AOSP.

Java nullability annotations may generate types that currently are not denotable in Kotlin:
class Java {
  void <F> foo(@NotNull F f) {}
}

Type of given value parameter should be not nullable under any substitution:
String/String?/String! because of annotation contract.

NB: Currently there is no full analogues for such types in pure kotlin

 #KT-10418 Fixed
 #KT-10594 Fixed