Threading, Native Methods, and ClassLoader Overhaul

I have completely overhauled the following components of Doppio:
* **Threading**: Doppio now has a `Thread` class, which encapsulates a single thread of execution, its stack, and its runtime loop. It also has a clearly-encapsulated simple thread scheduler, and now appropriately handles various JVM thread states (relating to monitors, parking threads, blocked on input, etc.). Previously, we would only schedule other JVM threads at pre-specified synchronization points *only* (e.g. locks), but if a thread was blocked on a network request, we would not schedule an alternative thread. This is no longer the case; Doppio will always run alternative threads if they are not blocked should the active thread become blocked for any reason.
* **Native Methods**: Native methods are now loaded from the in-browser filesystem, much like class files. The user of Doppio passes in a 'native classpath', which contains folder paths to native function definitions. Thus, users of Doppio can define their own native methods now without modifying a monolithic natives file.
  * Doppio now also includes a utility called `doppioh` that produces a native method template for a given package or class file. It can produce TypeScript *and* JavaScript templates.
  * Usage: `./doppioh  -classpath path/to/class/files -d path/to/output/directory class_or_package_name`
  * (Eventually, I will likely merge the native and regular classpaths so you can simply place your .js files alongside your .class files; they are separate now for convenience only.)
* **ClassLoader**: The classloader is now multithreading safe! I realize that this sounds weird, since JavaScript is single-threaded, but Doppio supports multi-threaded JVM applications, and a context switch can occur mid-classload. Previously, should a context switch occur mid-classload, and a second thread attempted to load the same class... bad things would happen. Now, the second thread will block until the first thread finishes loading the class. Hurray!
* **Heap**: Doppio now has a much better / rewritten heap implementation (in `heap.ts`).

I performed a quick benchmark of this new version of Doppio vs. the current stable version of Doppio on the Rhino JavaScript engine running in Doppio, and it appears to be 1.5X *faster* due to its cleaner bytecode loop. The code is also cleaner. It's a win/win!

The following issues are resolved with this refactor:
* #281 
* #274 
* #255 
* #221 (I removed the caching functionality; it caused many bugs, and the performance benefits are negligible)
* #218 
* #167 
* #162 
* #154 (Can register a faster version and will reset upon re-execution)
* #135  (I removed the caching functionality; it caused many bugs, and the performance benefits are negligible)
* #130 (Heap implementation is now integrated into `heap.ts`; implementation courtesy of Heap Expert @emeryberger )

I have also dramatically simplified the Doppio API, and have added an optional interface for running Doppio as if it were the java command line tool (e.g. `java -classpath /foo/bar -jar baz.jar`). I will document this soon.

It is likely that other issues related to compatibility are fixed. I plan to go through and update those issues after merging.

These changes all pave the way for further Doppio improvements, so stay tuned! :smile: