… a Java superclass

When a module M is prepended to a Ruby class E that subclasses a Java class,
the split constructor protocol only saw M's initialize (the effective method
after prepend) and never invoked E's own initialize, producing [:d, :c]
instead of the correct [:m, :e, :d, :c].

Root causes:
- tryInstall used clazz.searchMethod which found M's initialize (via prepend
  hierarchy) instead of E's, so oldInit was wrong
- splitInitialized had no way to express two Ruby initializes at the same
  reified-class level (M wrapping E), only a flat isLateral branch
- SplitCtorData lacked a clazz field so finishInitialize used getMetaClass()
  as the defining module, causing incorrect method lookup

Fix:
- tryInstall now uses clazz.getMethodLocation().searchMethod to capture E's
  own initialize as oldInit
- Add findIncludedPrependedModule helper to detect when the found method lives
  in an included prepend-wrapper for the base class
- Add isPrependedJavaCtorWrapper to identify this specific structural case
- In splitInitialized, handle the prepend-wrapper case by splitting M first,
  recursing into the prepend-wrapper's superclass for E's split, then chaining
  the two SplitCtorData via a new nested field
- finishInitialize recurses through nested first, ensuring M->E->D->C order
- Add clazz field to SplitCtorData so finishInitialize uses the correct
  defining module for direct (no-state) calls
- Fix isClassOrIncludedPrependedModule to use getDelegate() comparisons

Signed-off-by: Jimmy Tanagra <jcode@tanagra.id.au>