…r names

Fixes #24134

f99dba2 started emitting Java generic signature for mixin forwarders.

However, when generating Java generic signatures for mixin forwarders,
method-level type parameters could shadow class-level type parameters with the same name.

For example, when `JavaPartialFunction[A, B]` implements
`PartialFunction1[A, B]`,

```scala
trait Function1[-T1, +R]:
  def compose[A](g: A => T1): A => R = ???

trait PartialFunction[-A, +B] extends Function1[A, B]:
  def compose[R](k: PartialFunction[R, A]): PartialFunction[R, B] = ???

abstract class JavaPartialFunction[A, B] extends PartialFunction[A, B]
```

the generated mixin forwarder for `compose` in Function1 was like:

```java
public abstract class JavaPartialFunction<A, B> implements scala.PartialFunction<A, B> {
  public <A> scala.Function1<A, B> compose(scala.Function1<A, A>);
```

which is obviously incorrect, the type parameter `A` of
`compose[A]` is shadowed by the `A` in `JavaPartialFunction<A, B>`.

The `compose`'s type parameter should use an unique name like:

```java
public abstract class JavaPartialFunction<A, B> implements scala.PartialFunction<A, B> {
  public <T> scala.Function1<T, B> compose(scala.Function1<T, A>);
```

This commit fix the problem by
- Tracks class-level type parameter names when generating
  method signatures
- Renames conflicting method-level type parameters (A → A1,
  A2, etc.)

[Cherry-picked 4e284c5]