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)
This replicates an oddity in the Java extractor that it doesn't differentiate a specialisation Generic<T1, T2, ...> from the unbound type, if T1, T2, ... are Generic's declared type variables occurring in the same order. For example, in `class MyList<T> { void addAll(MyList<T> param) { ... } }`, the type of `param` is an instantiated type, but
gets extracted as an unbound type. This commit can be reverted (except for the improvement to isUnspecialised) if/when that is fixed.
