So we are closer to a realistic setup and can tell when we accidentally look up
a class in the wrong project.
Also allows us to have changes in a class but not to the class or its
package (i.e. same file).

While one might at first think that multiple changes should conflict if they
target that same start point, that is not necessarily true as long as no more
than one of them includes deletions: There may be an arbitrary number of
insertions at the same position (regular remapping never just inserts but
patterns can).

When we used to remap `a.pkg.A.Inner` we would apply both mappings (the one for
the inner class and the one for the outer class) at the same time, resulting in
`b.pkg.B.Inner.Inner`.
The direct cause being that we only checked conflicts for the range of the
respective expression (which is just `A` and `Inner` for Kotlin, and therefore
not conflicting) instead of the parent as we should have.

With that fixed, it now also becomes apparent that we need to apply mappings for
dot qualified expressions back to front (otherwise the outer class takes
priority), so that is the second thing this commit change.

When remapping the @At `target` argument, we used to only look at the mappings
for the target class but we also need to consider mappings for its super classes
and interfaces.
This commit now searches for the target Psi method and then uses the regular
remap method for PsiMethod to get its properly mapped name.

To ensure the mixin target is being remapped, even though the corresponding
PsiClass cannot be found.

E.g. there are no mapping entries for constructors cause their name is always
`<init>` but we nevertheless want to remap their argument types.
We cannot determine whether the name is ambiguous in the mapped
environment (because that check is based on the mappings), so we always keep the
arguments when it previously had ones.