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).
If this actually kicks off the execution of registered callbacks, `complete` sounds a bit confusing IMO. Maybe, something like `run`?