Fixes to re-enable JavaAdapter support

[space928]

This PR re-enables support for the JavaAdapter, this allows users to implement abstract classes and specific interfaces in JavaScript.

Example:

// Import necessary classes
const Runnable = Java.loadClass('java.lang.Runnable');

console.setDebugEnabled(true);
console.log("Testing JavaAdapter...");

// The JavaAdapter is added to the global context by calling `initStandardObjects()` in the KubeJSContext ctor
const test = new JavaAdapter(Runnable, {
	run: function () {
		console.log("Hello from the JavaAdapter!");
	}
})

test.run()

The JavaAdapter is needed to interface with certain mods that don't yet have a specific KubeJS integration such as CC-Tweaked which requires implementing the IPeripheral interface to define new peripherals.

It might be worth putting a disclaimer on the JavaAdapter support for now, as it has a mediocre surface area to test and for now should be considered experimental.

[LatvianModder]

Looks good! I'll still probably have to clean up formatting afterwards, but I only have 2 comments so far:

• Do the newly added static boolean toBoolean etc. methods in Context have to be static? Could you change them to be virtual? I like to have the option to override them in context implementations
• Why did you swap the order of arguments in convertResult(Context cx, Object result, TypeInfo c)? I usually prefer Context to be the first argument in any method its present

[space928]

The main reason for having context as the last argument for convertResult and toBoolean[etc] methods was to make calling them in the generated bytecode easier. The way the code is structured at the moment, the first argument for these methods is already put on the stack well before they are called (generateReturnResult() the method that generates the bytecode that uses these methods expects the Object to be converted to already be on the stack).

That being said it's not too much trouble to move context to the first argument (and hence make toBoolean etc virtual) by adding a SWAP instruction (which would presumably have a negligible if anything at all performance cost).

I'm happy to implement that if you want!

[amathieson]

Tested this on my instance by adding a ComputerCraft peripheral, seems to work well!

+1