JVM IR: Fix generic signatures for special bridge methods (KT-52929)

[sfs]

• Only modify generic signatures for declarations that erase to an override of a Java declaration with a different generic signature, instead of modifying all special bridges. This fixes KT-52929.
• Fix generic signatures for methods with generic types in Java. For example, getOrDefault is generic in its second argument and Map.remove has a generic return type. The code in GenericSignatureMapper contains a comment explaining what goes wrong with remove if we generate the wrong or no generic signature.
• Produce generic signatures on abstract bridge methods so as to avoid raw types in Java. See testSpecialBridgeTypesJava.
• Match the behavior of the Java compiler for special bridges with collection parameters. We currently produce a signature with a parameter like Collection<out Any?>, while the Java compiler generates Collection<*>. The two types are equivalent, but the latter is shorter. This is technically not breaking anything though, so I've put it into a separate commit.

---

For the implementation I started out using the existing tables in SpecialGenericSignatures, but they don't quite contain all the relevant information. For example, which methods are generic in their return values and which Kotlin class we should check for overrides (i.e., java.util.Map could be MutableMap or Map). Writing out these additional special cases is basically as much code as writing out all cases so I ended up with a new table in GenericSignatureMapper. After some more cleanup we should probably look into unifying all the different implementations again, but for now I think this is the cleanest solution without touching code in the old backend.

As a nice side effect this gets rid of another use of IrBasedDescriptors in MethodSignatureMapper.