The issue here was that we super calls would sometimes fall back on reflective invocation when more than one subclass was involved. This had the effect of restarting the invocation chain back at the bottom of the hierarchy (from the self object's class) due to the nature of reflective invocation (it always calls the lowest override).

The fix here pulls the super invocation logic back from within the Java integration guts and into the Ruby-level super logic, so we can look up an appropriate super shim method to invoke at the proper level.

This fix will need to be refined in the future, using some of the following ideas:

• Rewrite such supers to be a different instruction. We should be able to detect this in the same way we detect super in the initialize methods of Ruby/Java subclasses. Alternatively make the check into a boolean, but this keeps some unnecessary overhead when the super invocation does not involve a Ruby/Java subclass.
• Restructure JI invocation to be able to handle this case, by passing through the definingModule from which the super call should originate. This was not possible using the standard DynamicMethod call paths, but enhancement may be possible.
• Improve the caching of this and other forms of super, which may inform a better design.

Includes simple test cases for the examples in #6718.

Fixes #6718.