Avoid ScriptingContainer#get("Constant")

For some unknown reason, it does not seem to work when the Java-code is
executed from within JRuby. In that context, the get call always returns
null (unless a thread-safe scripting container is created). The thread-
safe scripting container does not work at all from within Hadoop, as
variables sharing between threads becomes difficult.

Any instance of Kernel was replaced with null, as the default receiver
(main) has Kernel included, and thus should work exactly the same way.

For other constants, the get call was replaced with the more expensive
alternative runScriptlet which seems to work independent of context.
Add support for custom input formats

This adds an InputFormatProxy along the same lines as the other proxies.

Unfortunately, I couldn’t really figure out how to write a meaningful
unit test, so I implemented a (rather contrived) custom input format in
the integration tests to at least make sure the code runs.

A limitation is that the splits returned from the input format must be
standard Hadoop splits, as any input split must be serialisable and
that would require a significant amount of code.
Rename getInstance to wrapInstance
Dynamically get JobContext configuration

As JobContext changed from class to interface between Hadoop 1 and 2,
we get an IncompatibleClassChangeError if we try to use the proxy class
compiled to either of the versions with the runtime of the other.

By getting the configuration method dynamically, we ensure that you can
compile the proxy class with either Hadoop version, and independent of
version used, it should still work together with either runtime.