This PR does two things for defining modules and classes:

1. Eliminates use of runtime except in the primal boostrapping phase before the first ThreadContext is defined. These runtime consumers will only ever be used internally by us in a few places because...
2. Define an @JRubyAPI annotatied way ot defining type for native extensions

The new API itself is intended to allow composition through method functions in a builder style. For this old code:

    public static RubyClass createHashClass(Ruby runtime) {
        RubyClass hashc = runtime.defineClass("Hash", runtime.getObject(), RubyHash::new);

        hashc.setClassIndex(ClassIndex.HASH);
        hashc.setReifiedClass(RubyHash.class);

        hashc.kindOf = new RubyModule.JavaClassKindOf(RubyHash.class);

        hashc.includeModule(runtime.getEnumerable());

        hashc.defineAnnotatedMethods(RubyHash.class);

        return hashc;
    }

Now looks like:

    public static RubyClass createHashClass(ThreadContext context, RubyClass Object, RubyModule Enumerable) {
        return defineClass(context, "Hash", Object, RubyHash::new).
                reifiedClass(RubyHash.class).
                kindOf(new RubyModule.JavaClassKindOf(RubyHash.class)).
                classIndex(ClassIndex.HASH).
                include(context, Enumerable).
                defineMethods(context, RubyHash.class);
    }

So by chaining in a builder style we remove a lot of repetition and the need to debate on variable names (at least a good portion of the time).

In doing this I realized someone had started the tradition of making the variable name match the Ruby name. So instead of objectClass it would be Object. This convention is not 100% possible but it is pretty close. This PR adopts this when possible and changes the name when it isn't. It makes the reading of these definition feel more DSLish.

Another thing I changed was create functions tend to pass in what they use in the definition. So passing in, for example, Enumerable module as a parameter:

1. Visually helps on call side say what the new type is using
2. Eliminates a getter in many cases (no more runtime.getObject or objectClass(context) in new API terms).

The main risk here is largely that I did change non-private signatures related to creating our types internally. I cannot think of a possible reason anyone would be trying to call our bootstrapping methods. I think this is safe.

• Future Work

There are a couple of methods which accept ThreadContext but do not use them. The intention here is that I know beneath the covers we are using context or runtime. These should be pushed through where possible. The primal uses might force us to always have runtime very deep in some methods but we need to keep pushing runtime out in favor of thread context.

Speaking of ThreadContext we need to figure out a way of reducing the few classes above to get closer to being runtime free for all definition. I am not sure it is possible but I think we can get so close perhaps we have some duplicated logic only for them and the rest of the system happily is using context-based APIs.

I am certain there are more methods in module,class,irubyobject,basicobject which should be marked as @JRubyAPI and possibly replaced with the composable style. I did get almost everything in this massive PR