Fix MethodUtils.getMatchingMethod false ambiguity on boxed arguments

[alhudz]

MethodUtils.getMatchingMethod ranks overloads with the private distance helper, which charges a flat +1 for any autoboxing conversion. For a primitive argument that makes int to Integer and int to Number both score 1, so when a class declares both f(Integer) and f(Number) the call getMatchingMethod(cls, "f", int.class) puts two candidates in the same distance bucket and throws IllegalStateException: Found multiple candidates, even though javac resolves f(someInt) unambiguously to f(Integer).

The fix keeps the flat penalty when a primitive boxes to its exact wrapper but adds the supertype cost when it boxes to a supertype, so int to Integer ranks strictly below int to Number. distance is private to getMatchingMethod, so the change stays inside that resolver; the auto-unboxing direction and every existing resolution are unaffected.

[garydgregory]

Thank you @alhudz , now merged 🚀 and deployed to snapshot builds in https://repository.apache.org/content/repositories/snapshots/org/apache/commons/commons-lang3/3.21.0-SNAPSHOT/