refactored GremlinJSPipeline

As I'd discussed recently, I wanted to try and refactor GremlinJSPipeline to be completely async.

Having experimented with that however, I learned it's much slower due to the sheer number of threads being spun up for each chained operation. From there, I tried to refactor GremlinJSPipeline to only execute the potentially risky operations (e.g. start) to be asynchronous. That worked OK, but the code was terribly messy and it seemed best in the end to just throw an error to the user (perhaps it should be configurable?) informing them to resolve the Iterable instance to an Iterator instance.

This is kind of crappy, and who knows if databases other than titan lazy-load when resolving an iterable to an iterator - at the end of the day I'd just like to ensure users don't experience poor performance due to the bindings.

Anyways, while at the end of the day all I did was add an asset, I'd done some extensive refactoring to the pipeline wrapper when trying to make it async that I felt was worth PRing. It trims about 200+ SLOC from the bindings, making the pipeline class a much slimmer overall wrapper. The highlights are:
 * added a `parseVarargs` function to aid in coercing parameters to arrays for functions that expect a vararg parameter. Initially I thought it'd be nice to update node-java to support calling vararg functions (it currently expects an array to be passed for a vararg parameter) but that turned out to be not very straight forward.
 * changed the way we invoke operations that take in a closure (take a look at `convertClosure`) to simplify the binding logic (which also avoids allocating binding objects for each pipeline)
 * went through and added a few new / removed a few old pipeline operations and sorted them all to match GremlinPipeline.java

I haven't _extensively_ tested all of the pipeline operations - it'd probably be a good time to add basic unit tests that try to invoke each method signature to make sure they work as expected.