This logic needs to walk up to the nearest non-singleton, non-
include wrapper to find the "real" module, since constants do not
live on those other "non-real" module types.

Fixes jruby#6708

The frame class is frequently pointing at the include wrapper for
a given module, in order to indicate where super should start
from. However with the "real module" logic this causes the target
of the autoload to not be on that included module, but on the
superclas of the include wrapper. This led to breakage in the
Kernel#autoload specs, since they require that Kernel.autoload and
Kernel#autoload define the constant on the included module.

We do not have a concept of cbase in our codebase, but the cbase
in CRuby is used as the target for class variables and other
class-y things that can be done from within a method body. The
logic in IRRuntimeHelpers.getModuleFromScope seems to
find the appropriate location.

We do not do class variable targeting exactly right (e.g. in
cloned modules) so this logic is not quite matching CRuby, but it
does pass the original case in jruby#6708.

This still fails a regression test from "JRUBY-6570" but it
appears that the original fix for that issue did not really fix
the problem. It merely made the expected case pass by always using
Object as the target, which is clearly not correct.

In order to start using the language of CRuby I have introduced
a new method getCurrentClassBase that should eventually be
equivalent to CRuby's vm_get_cbase.

This spec defines current behavior of CRuby, but that behavior is
rather questionable due to unexpectedly different targeting of
autoload versus constant definition. We believe this regression
spec was never truly fixed in JRuby and merely happened to pass,
due to a naive fix that was still incorrect behavior but close
enough to make the given test pass. In order to move forward with
the fixes for jruby#6708 we are moving this spec into rubyspec via
ruby/spec#839, so we can discuss whether this is really correct
behavior or not.