Iwillig/remove queue async

@bcamper 

Looks like I was able to get all of the queue-async library out of tangram. Thanks to @meetar for helping with this. 

Let me know if you think this is okay to merge. 

So here's what I think was happening. Modes are singletons, and use a prototype-based inheritance pattern with `Object.create` to implement this. So for example the `Polygons` mode is defined in this file at compile-time, and then additional modes can be derived from it (defined via the stylesheet) using `Object.create` at run-time. But the `loading` property not defined on the 'base object', `RenderMode`. So when that property is later checked [here](https://github.com/tangrams/tangram/pull/61/files#diff-9d9702aee88c2affd926c674605d3a01R73), when we try to compile the mode, it was probably falling back to the value of the parent mode via the prototype chain, e.g. if the `Polygons` style was compiling, and then a call was made to compile a custom mode derived from `Polygons` (e.g. the water mode in the demo), it would think it was already compiling, and short-circuit the compile process by returning early. We could have checked `hasOwnProperty` (and still could to validate this theory...), but, it is just bad practice to not be defining it on each object at the time of creation (the `init()` method in this case). So adding it to `init` is the right thing to do; we should probably make a sweep for others that might be lurking too.

What I am unsure about is why this branch switch to promises would cause it to trip up, vs. not seeing this behavior with the Queue library. Possibly something about order of operations / luck?

This is one of those reasons I have never felt comfortable with this inheritance pattern, so we might want to port it (though inheritance with singletons is kind of a unique case, and not really a natural fit for ES6 classes either). I've had a couple other gotcha bugs from the same parent/child property relationship.