kotlin(OVERLOAD_RESOLUTION_AMBIGUITY) Java superclass ambiguity int/Integer

```kotlin
class StackCount: Object2IntOpenCustomHashMap(IntArrays.HASH_STRATEGY) {

fun change(stack: IntArray, count: Int): Int {
val newAmount = getOrDefault(stack, 0) + count
if (count == 0) return newAmount
if (newAmount == 0) removeInt(stack)
else put(stack, newAmount)
return newAmount
}

}
```

Screenshot


```log
Class 'StackCount' must override public open fun get(key: IntArray!): Int? defined in it.unimi.dsi.fastutil.objects.Object2IntMap because it inherits multiple interface methods of itkotlin(MANY_INTERFACES_MEMBER_NOT_IMPLEMENTED)
Class 'StackCount' must override public open fun remove(key: IntArray!): Int? defined in it.unimi.dsi.fastutil.objects.Object2IntMap because it inherits multiple interface methods of itkotlin(MANY_INTERFACES_MEMBER_NOT_IMPLEMENTED)
```

Screenshot


```log
Overload resolution ambiguity:
public open fun getOrDefault(p0: Any!, p1: Int): Int defined in io.github.powercraft.item.StackCount
public open fun getOrDefault(p0: Any!, p1: Int!): Int! defined in io.github.powercraft.item.StackCount
public open fun getOrDefault(key: IntArray!, defaultValue: Int!): Int! defined in io.github.powercraft.item.StackCountkotlin(OVERLOAD_RESOLUTION_AMBIGUITY)
```

Screenshot


## Regarding getOrDefault: Educated guess: Integer/int merging into the same type in Kotlin. ##


This image from IntelliJ shows that it also struggles to resolve when I try to override as one takes and returns Integer (->Int!) and the other takes and returns int (->Int). But IntelliJ doesn't have an issue with it in the first place, though. So it just eats it without redefining `getOrDefault`. Would love if this LSP would also handle it that way.

## Regarding why I need to override `get` and `remove`, I have no clue. Both are deprecated.

But I could imagine it to be related to the same problem if multiple interfaces define slightly different methods (int vs Integer) and thus aren't fused automatically because the linter doesn't know which to assume. (again, IntelliJ doesn't even complain and the compiler compiles)