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)
A simple rewrite to use API graphs instead.
The handling of falsy values is potentially a bit more restrictive now,
as it only accounts for local flow. We should probably figure out a
better way of capturing this pattern, but I felt that this was out of
scope for the present PR.
