jextract/jni: Inherited protocol requirements can be renamed inconsistently when a child adds an overload #941

Problem

When a child protocol adds an overload of an inherited requirement, the generated Java box can rename the inherited method based on the child's overload set. The parent Java interface still declares the method under its original name, so the child box does not implement the parent interface and Java compilation fails.

Example

public protocol NamingParent {
  var id: Int64 { get }
  func value(number: Int64) -> Int64
}

public protocol NamingChild: NamingParent {
  var tag: Int64 { get }
  func value(text: Int64) -> Int64
}

struct NamingValue: NamingChild {
  var id: Int64 { 1 }
  var tag: Int64 { 2 }

  func value(number: Int64) -> Int64 { number + 10 }
  func value(text: Int64) -> Int64 { text + 20 }
}

public func makeNamingChild() -> any NamingChild {
  NamingValue()
}

Swift argument labels distinguish the two requirements, but Java cannot represent both as value(long) on the child interface.

The parent interface exposes value(number:) as value(long). However, the generated child box can emit valueNumber(long) for that inherited requirement after considering the child's overload. This does not implement the parent's value(long) method.

The inherited requirement should keep the name declared by the parent interface. For example, the generated bindings could use value(long) for value(number:) and valueText(long) for value(text:). The Java interfaces, box methods, and JNI thunks should use consistent names so that both operations dispatch to the correct Swift requirement.

Reference workaround implementation: qoncept#3