Opcode Revamp: Cleaner code + speed improvements + self-hosted JCL

In the first version of Doppio, JVM instructions were represented as individual objects. This design proved handy for 'stashing' information in particular instructions, such as classes, to prevent unneeded work the second time around, but was a poor design for an interpreter. Doppio allocated a single object for every instruction in every class file. However, as it was a legacy implementation from the very first prototype implementation of Doppio, and since a number of other areas of Doppio badly needed work (e.g. file system, threads, ...), we never had time to reengineer the interpreter loop for better performance and readability.

Until now. Now, every JVM instruction is a single function in the `opcode.ts` file. Doppio operates over the raw bytecode bytes, straight from the `class` file. Doppio rewrites opcodes that require one-time checks, usually to ensure a class is initialized or resolved, to `_fast` versions that omit the check once the check passes. Previously, Doppio would accomplish this same feat by overwriting the `execute` function in the opcode object.

I initially feared that this new interpreter loop would be slower. While the initial "1 object per opcode" design is terrible from a memory allocation standpoint, it might have enabled JavaScript engines to do per-instruction optimizations.

However, some quick benchmarking shows speedups across the board!

| Browser | Benchmark | Speedup |
-----------------------------------------------
| Chrome 38 | Rhino | 17.1% |
| Chrome 38 | Javac | 29.7% |
| Firefox 33 | Rhino | 26.3% |
| Firefox 33 | Javac | 13.6% |
| IE 11 | Rhino | 58.9% |
| IE 11 | Javac | 35.5% |

These numbers are quite encouraging. 

In addition, this PR moves us to a *self-hosted JCL*, which means that building Doppio is *much* easier than before.

Look forward to many other DoppioJVM improvements coming in the following months!