Array<*> can't be queried for an argument type, and IntArray doesn't have an argument at all; both were previously causing the extractor to fail to extract the whole file due to throwing an exception.
I can't reproduce the exact circumstances, but these sometimes get "<anonymous parameter X>" names and sometimes get "$noName_X" names. Whichever way, avoiding extracting a synthetic name seems safest; anyone finding the .class file and not reading the metadata indicating it came from a `_` will extract the binary name selected, or else QL will
invent a name.
Prior to Kotlin 1.7 the gratuitous `?` was ignored for typing purposes; now it yields a `String?`. We should make the test work everywhere by using a real nullable type.
Kotlin permits introducing a `? extends ...` wildcard against an Array even though the class is final, so long as its argument itself can be extended (i.e. isn't final or is another array type satisfying this condition).
Contravariant arrays get lowered to Object[], and are subject to automatic `extends` wildcard introduction, unless their element type was already Any.
This should lead to better Java/Kotlin correspondence since the Java extractor will naturally name trap files for JVM names, and avoids a specific bug (tested) where MapsKt.iterator's two overloads (one taking `Map` and one `MutableMap`) are JvmName'd differently since their Java-lowered signatures would be identical. Without this change only
one of the iterator overloads would get extracted leaving the other one a dangling reference.
The Kotlin authors changed this to avoid a clash on List<Int>, but we must reverse the renaming so the Kotlin and Java views of the same class file extract alike.
Collection, List and Map all define various methods which are either made more generic in Kotlin (e.g. `remove(Object) -> remove(E)`, `containsAll(Collection<?>) -> containsAll(Collection<E>)`), or are made invariant (e.g. `addAll(Collection<? extends E>) -> addAll(Collection<E>)`). This substitutes the types back to their Java signatures,
thereby avoiding differing trap labels and duplicated methods for these types and their descendents.
