fix: discover inherited test methods when running child classes

[Vinay Kumar Maheshwaram (sudovinay01)]

Summary

When running a test class that extends a test base class, inherited @Test methods were not included in discovery. This could make the child-class run appear successful while silently skipping tests defined by its parent.

This change discovers eligible test methods throughout the superclass hierarchy and lists inherited methods under the child test class.

Changes

• Traverse superclasses when discovering a class’s test methods.
• Skip private superclass methods and avoid duplicate methods when the child overrides a method.
• Associate inherited test items with the child class so they are included when that class is run.
• Add regression coverage for inherited methods, overrides, and child-defined methods.

Gradle source-set configuration and task behavior are unchanged.

Reproducer

https://github.com/sudovinay01/repro-java-issue

Validation

• java-extension/mvnw.cmd clean verify -Declipse.p2.mirrors=false passed.
• The regression test verifies inherited methods are discovered for a child class.
• Manual check in VS Code confirmed running AppMainSourceTestChild executes both the inherited and child-defined methods.

images of issue

### VScode after fix

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.

[Vinay Kumar Maheshwaram (sudovinay01)]

wenyt (@wenytang-ms) I have addressed your three review comments in commit 17e6b99, added regression coverage, and verified the Java reactor. Could you please take another look when you have a chance?

[wenyt (wenytang-ms)]

If the base class comes from a dependency JAR, running an inherited test like base(TestInfo info) on its own fails here. getCompilationUnit() is null for a binary method, so we get Cannot get compilation unit of methodbase. Running the whole child class avoids this, but running or debugging just that method doesn't.

Could we get the parameter types from an IMethodBinding for binary methods instead of looking for source? We can leave the current source-method path as-is and keep using the child class for execution. A test with a compiled base class and a method parameter would catch this.

[Vinay Kumar Maheshwaram (sudovinay01)]

Addressed in 57344f1. For parameterized JUnit 5/6 methods without a compilation unit, the launch resolver now uses ASTParser.createBindings() to obtain an IMethodBinding and formats its parameter types. The source-backed AST path remains unchanged, and the child class is still used as the execution target. Added a regression with a parent compiled to target/test-classes and a child project referencing it as a binary library; it verifies the selector example.InheritanceBinaryChildTest:base(org.junit.jupiter.api.TestInfo). The full Java reactor passes all 12 plugin tests.