We used to get alerts for the class around a local function, a lambda,
or a function reference, which we give name "". Now those are marked as
compiler-generated, and the query ignores compiler-generated types.
A bunch of test expectations change because 7f531d8426 means that we now see (a) local variable declarations with source locations covering only their identifier, not the whole statement, and (b) more SYNTHETIC_OFFSET values for the parts of a destructuring assignment
or initialiser, which show up as file.kt:0:0:0:0 in DbLocation form.
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.
Previously individual top-level file declarations relied on their corresponding file-class to declare their `File` instance, but this can be scuppered by a Java extractor replacing that file-class and identifying a different file location.
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.
This avoids extracting the default value expression in more than one place, which causes inconsistencies for e.g. anonymous classes, which expect to have a single `new` expression associated.
In this circumstance the compiler seems to generate a specialised version of the implementing function with its argument type replaced by the interface-implementing child class' type parameter. However it stores a back-pointer to the real declared function, which we should use as the call target.
This arises when a generic class extends one of its parameters; for example, `class G<T> { val T.v; get() = 1 }`, where specialisation `G<List>` should generate a method specialisation `getV(List)`.
