This adds a single plain Gradle project that uses a modern Kotlin build script (i.e. settings.gradle.kts and no build.gradle.kts), plus basic Android samples exercising the possible permutations of: (old vs. new-style build script, Groovy vs. Kotlin build script, wrapper present vs. absent)
Old vs. new style tests our recognition of different cues that this is likely a Droid project and requires `gradle assemble` not `gradle testClasses` (the example given at https://developer.android.com/studio/build/#top-level changed style as of plugin version ~7.3.0).
Groovy vs. Kotlin build script language checks that the regexes recognising Android dependencies and versions work for both build script kinds.
Wrapper present vs. absent exercises the autobuilder logic that guesses an appropriate Gradle version and sets it up in the event the Gradle wrapper isn't provided.
This causes them to render properly in PrintAst output due to `getAnnotationElement` working as expected, and will hide the fact that they are represented by raw types in bytecode.
This is imperfect since arguments to those annotations will be missing, but at least the common case of a plain `@NotNull` or `@Nullable` will be right, and the `@NotNull`s introduced by the Kotlin compiler will be present as expected.
This is a shortcoming of the Kotlin extractor, but at least this way we don't introduce an inconsistency if the annotation is later seen from .kt source or by the Java extractor
Java's regular strings are formatted as they appear in source, but we don't easily have this information available in Kotlin. During annotation extraction however it guesses a source rendering because the source is not necessarily available. By formatting to match the annotation extractor, we prepare to ensure consistency with a Java database
when extracting annotations as seen by Kotlin.
This fixes two mistakes: return-type extraction not imposing a wildcard where a Java prototype explicitly uses one, and nested wildcard detection quietly failing due to not looking through a `JavaWildcardType` correctly.
I add a variant of the `kotlin_java_lowering_wildcards` test where Java prototypes are only seen from Kotlin, to be sure extraction is working as expected.
