Deferrable render

Allows view rendering to be executed in either a sync or async manner depending on the context. Generally in server side mode async is preferred to prevent blocking the event loop while in client mode sync is preferred to prevent arbitrary reflows, etc.

This attempts to normalize major components of the render pipeline to allow for both without too much chaos. This is done through the psuedo-internal deferred API, which allows for an arbitrary number of tasks to be scheduled in the manner most appropriate to the rendering context's needs.

For current listeners of the `append` and `before:rendered` events, it's not necessary to use the new deferred object that is passed as the final API argument. Any code that is executed sync in those event handlers will continue to behave as before, providing they do not have dependencies on code that is running in a deferred task.

Breaking changes:
- `setView` callers can not assume that the operation has completed after the call returns unless they pass the `async: false` flag.
- `rendered:collection` now occurs prior to the `rendered` event
- `append` and `before:rendered` events can not assume that other handlers have executed prior to their own execution unless they utilize the `deferred.exec` API which does guarantee this case (although the existing concerns of did you register before the other guy hold and this is generally ill advised to make these assumptions in loosely linked event code).
I don't really like `Deferrable` name, looks more like a task queue to me.
Also, looks like `Deferrable` can be split into two classes, one for sync mode and the other for async mode. Sync mode class implementation becomes trivial, and async mode class implementation becomes simpler, because you don't need to do `if (complete)` checks all over the place. Dispatch between these two can be made in wrapper like this:
`function taskQueue(complete) { return complete ? asyncTaskQueue(complete) : syncTaskQueue(); }`.