Summary

• Addresses Tim's review feedback on Add PowerMockWhiteboxToJavaReflection recipe #944 regarding the use of .getClass() for resolving parameter types in the invokeMethod rewrite.

The previous implementation used arg.getClass() to determine parameter types for getDeclaredMethod(). This returns the runtime concrete class, which fails when the method's declared parameter type is an interface or parent class (e.g., method expects List but items.getClass() returns ArrayList).

Resolution strategy (three tiers)

1. Resolve the target method declaration — walks the target object's type hierarchy via getMethods(), finds a unique match by name + arity, and uses the method's declared parameter types. Handles subclass/interface mismatches correctly. Adds necessary imports for parameter types not already in the file.
2. Fall back to argument's compile-time type — when method resolution fails (ambiguous overloads, missing type info), uses the expression's AST type. Still better than runtime for interface-typed variables.
3. Fall back to arg.getClass() — when no type info is available at all, preserves the original runtime behavior.

Use cases now covered by tests

• Single string argument — String.class instead of "World".getClass()
• Multiple arguments — verifies correct template/arg array indexing with 2+ parameters
• Primitive argument (int) — generates int.class instead of autoboxed Integer.class
• Interface-typed variable (List<String> items = new ArrayList<>()) — resolves to List.class
• Concrete variable but interface parameter (ArrayList<String> items, method expects List) — resolves to List.class via method declaration lookup, adds import java.util.List