wrap-java: Update subtyping logic for generic method overrides

[sidepelican]

This PR is likely the final part of the improvements for #599.

In Java,

• Executable defines: Class<?> getDeclaringClass()
• Constructor overrides it as: Class<T> getDeclaringClass()

Currently, wrap-java identifies these as the same method signature and adds the override keyword in Swift.
However, since Swift does not recognize a subtype relationship about them(JavaClass<JavaObject> vs JavaClass<T>), it results in the following error:

.../Constructor.swift:113:22: error: method does not override any method from its superclass
111 |   /// ```
112 | @JavaMethod
113 |   open override func getDeclaringClass() -> JavaClass<T>!
    |                      `- error: method does not override any method from its superclass
114 | 
115 |   /// Java method `getAnnotation`.

To resolve this, I have updated the type-checking logic to be more strict:

• In Type.isEqualTo(_:), resolved an issue where Class<?> and Class<T> were incorrectly treated as identical types.
  • Removed the call to adjustToJavaBounds
• In Type.isEqualToOrSubtypeOf(_:), changed the logic so that types with different generic arguments are no longer considered to have a subtype relationship.

[sidepelican]

Unfortunately, The override being treated as overload, explicit type annotations are now required. I believe this is unavoidable.

[ktoso]

There's probably no great way to avoid this... Unless we suffix the methods in the subclass? It might be an inherent incompatibility of how swift and java do overrides though

Open to sneaky ideas, maybe @DougGregor might have some?