Migrating native methods over to experimental new format.

Currently migrated some helpers over to java_object as a hack (to prevent
burdening util with imports). Will clean those up as they relocate onto
object, as is more proper.
Fixing import paths.
Adding java_lang.

Removing outdated ResourceBundle native.
sun/misc natives.

Typing fixes found some fun bugs, too.
java_io converted.
Moving networking/nio natives.
Migrating sun/reflect natives.
Migrating sun/management.
Converting sun/net.
java/security and sun/font.
classes/doppio converted.

All native methods have now been converted into this new format. Now, I
can modify the VM to use these new files.
Initial native registration mechanism.

For use by JCL natives, which we'll load up when the script loads.

I also realized that doppioh accidentally also grabbed trapped_methods, so
I may need to move those out.
Misc cleanups. Reintroducing trapped_methods.

Doesn't run yet. Need to hook up native-finding logic with JVM, and hook
the JCL natives into the build system.
Trying to get natives to work in dev mode.

Hacking them in there right now so I can checkpoint this fix.

I'll make it all better when I address control flow next.
I'm so done with our control flow.

The native refactoring triggered some weird control flow bug, so I'm just
trashing it all. We know all of the JVM oddities and corner cases, and we
know how to get it equivalently right this time, but with much less code.

I've finished a first pass at a Thread implementation. I'm planning on
completely removing the RuntimeState object.

We're going to have a:
* JVM, which has a reference to a
* ThreadPool, which has references to
* Thread objects

The JVM and individual threads will have access to the bootstrap
classloader for convenience.

Instead of passing around RuntimeState, we'll pass around Thread.

Here's what needs to be done:
* [Simple] Migrate monitor logic to ThreadPool.
* [Simple] Migrate thread scheduling logic to ThreadPool.
* [Simple] Migrate JVM bootstrap logic into JVM.
  * Should be much saner this time.
* [Simple] Migrate the new native method code into JVM
  * Should be a copy+paste job.
* [Chore] Rewrite ClassLoader to use sane control flow.
  * Planning to use the async library to make it easy to execute sequences
  * of async tasks.
* [Chore] Rewrite opcodes/natives to reference *thread* rather than *runtime state*.
  * 90% regular expressions, 10% making code cleaner.
* Get the tests working again.

No more fake frames, no more stack manipulation logic in every file, no
more crazy.
Monitor object, migrated to live on Java objects.
Shiny new classloader.
Small tweaks.

Need to migrate the opcodes over to using the thread next, and tweak the
bytecode loop a bit.
Part 1 of the Great Bytecode Drudgery.

Bytecodes are now 100% responsible for incrementing the program counter.
Before, we had tons of awful hacks that hacked around the implicit PC
increment in the main bytecode loop. Now, bytecodes are responsible.

I've also added a flag to the BytecodeStackFrame that signals when the
bytecode loop should return to the thread runner. This adds a little extra
responsibility to the bytecodes, as they now need to set the flag if they:
* Throw an exception.
* Return.

I'm might add a helper later for these.

Return opcodes now check if they are returning from a synchronized method,
and now appropriately call monitorexit. No more terrible hackery!

You may wonder why I switched from lambda syntax to function syntax.
Lambdas do not allow me to reference `this`, whereas functions do. I need
`this` to run `this.incPc()`. Unfortunately, TypeScript has no idea what
`this` refers to, so these lambda'd opcodes are going to be partially
untyped.

Finally, we used to 'resolve methods' by ensuring that all exception
classes are resolved prior to the method running. I've removed that
requirement, and have a TODO in there to make exception handling
asynchronous, giving us the freedom to lazily resolve exception classes.

It's going to be interesting to see how performance changes after I'm
done.

Also, did I mention that our type coverage is getting better and better?
The nasty bits of DoppioJVM were largely untyped. Now we have types
everywhere. Yay!
Opcode Drudgery Part 2.