Make extraction messages `warning` if code is still extracted regardless of the reported issue. Make extraction messages `error` if some code is not extracted.
We had a global set of labels for generic specialisations that we'd
extracted, but these labels could contain references to other labels,
and thus you can get false collisions between labels for different TRAP
files. We now only keep the set for a single TRAP file, and live with
the extra TRAP duplication that we get from that.
For example, in implementing Producer<T> by an actual lambda of type () -> Int, the return type should be Int, not T. This produced type-variable-out-of-scope consistency check failures.
These should be handled the same as regular methods: extract type accesses for parameters and methods only if we're extracting "from source", i.e. at some point we're descended from extractFileContents.
Previously we extracted them whenever something was non-external, but this led to re-extraction when an instance of a generic type defined in source was extracted multiple times.
This is both consistent with the Java extractor's behaviour, and prevents us from trying to refer to anonymous types (e.g. anonymous objects that directly initialize properties) out of scope.
This allows the particular case of Collection.toArray(IntFunction<T>) to match, since both Java and Kotlin functions take an IntFunction<T> but they use different function-local type variables.
This would also allow toArray(Array<T>) to work similarly.
This didn't appear to be necessary because the Kotlin and Java versions of Map (for example) are designed to be compatible, but in certain cases their functions have the same erasure but not the same type (e.g. Map.getOrDefault(K, V) vs. Map.getOrDefault(Object, V).
These have different erasures which was leading to callable-binding inconsistencies.
These include Collection.size() for example, which has a Kotlin property called `size` but whose getter is not named `getSize()`.
These would normally be accounted for using `@JvmName`, but some core methods are lowered by a special compiler pass instead.
(As before, these are not really unspecialised, they are instantiated by their own type parameters, but this replicates the behaviour of the Java extractor)
