Better event management

[parasyte]

DOM events are great for asynchronous processing, but they are also troublesome for allowing some actions to be done outside of the melonJS main thread. #346 and #358 are examples of how DOM events can interact with melonJS poorly by creating race conditions. #395 is also related, since the DOM events are only enabled by specific user-initialization calls.

In this ticket, I want to expand upon minpubsub to do all event handling within the melonJS main thread (which starts execution in _renderframe() : https://github.com/melonjs/melonJS/blob/master/src/state/state.js#L397)

Conceptually, any process which fires off-thread (DOM events, timer callbacks -- including Function.prototype.defer(), etc.) needs to immediately place a callback into a list where the main thread can run it. And we will expose this API for any custom events that a user might want to add. This is the only way to guarantee that async callbacks will be called without races.

I've seen a similar API in libraries like Chipmunk-physics, where the user may want to perform specific actions at certain points within the collision phases, for example. With melonJS, we might have similar event phases, like pre-update, post-update, pre-draw and post-draw (to name the obvious ones)

post-update and pre-draw are separate event phases because the timing of these phases will be different when frame skipping is enabled -- see #346 (comment) for a detailed explanation.

That will allow us to do things like: handle all input events in the pre-update phase, and handle all deferred calls in the post-draw phase. Or switching things around as necessary.

[parasyte]

Also, a recent post on the forum: https://groups.google.com/d/msg/melonjs/uVF5dorzf5Q/qd8KFBy6CEwJ This ticket will solve that issue.

[parasyte]

Linking #118