All transitions are now async

Previously, `transitionTo` was sync, while `handleURL` was
async if the target handlers' `deserialize` returned a
thennable. This sometimes sync / sometimes async approach
led to a lot of subtle problems with maintaining consistent
behavior between transitions and page-refreshes or back/forward
navigation. Issues include:

- Ember's `redirect` hook is neutered for transitionTo with
  promise contexts since it will evaluate even before the
  promise has had a chance to resolve. Of course, you can
  manually put a .then handler on the object before you call
  transitionTo, but this is needless complicated, and your
  code is now forced to implement two styles of async transitions,
  in in the case of a failure, you will have already fully changed
  the router, rendered templates, etc etc etc.
- You can't perform any logic before the route's entered
  to determine whether the transition should be halted or
  redirected (unless you're in handleURL, which is a
  minority of the time). This also leads to a lot of
  complicated redirect tracking logic that's unfortunately
  had to make its way into Ember.
- Generally speaking, any sort of authentication-based application
  will get bitten by these inconsistencies in a manner that can't
  actually be hacked/worked around in a satisfactory manner
  (many, many people can confirm this).

The solution to all of the bizarre corners cases is to embrace
async, make it the expected/assumed case, and unify the behavior
between URL changes and direct/explicit transitionTo's. Specifically,
this PR has done the following:

`transitionTo` and `handleURL` are async
----------------------------------------

`transitionTo` and `handleURL` are both async operations that
return a promise that resolves if the transition ran to completion
and rejects if it failed. So, clients must change things like

    router.transition('foo', Foo.find(123));
    someOperationThatDependsOnTransitionHavingTakenPlace();

into:

    router.transition('foo', Foo.find(123)).then(function() {
        someOperationThatDependsOnTransitionHavingTakenPlace();
    });

API Alteration: `deserialize` removed, replaced w/ hooks
--------------------------------------------------------

`deserialize` has been removed in favor of a few hooks for validating
an attempted transition. The new API is described here:

https://gist.github.com/machty/5584681
https://gist.github.com/machty/5622031

Here is an overview:

    handler = {

      // First hook called when attempting to enter a route.
      // Can transitionTo, throw an error, or return a promise
      // that does the above.
      beforeModel: function(resolvedParentModels) {

        // The `error` hook will receive this reason.
        throw "Some error";

        // ...or...
        return new RSVP.Promise(function(resolve, reject) {
          // The `error` hook will receive this reason.
          reject("Some error");
        });
      },

      // This gets called unless a context object was passed
      // from transitionTo.
      model: function(urlParams, resolvedParentModels) {
        return Model.findWithParentId(resolvedParentModels.post.id);
      },

      afterModel: function(model, resolvedParentModels) {
        // model is the resolved result of the model() hook or
        // whatever was passed in via transitionTo.
      },

      // Receives any of the thrown errors or rejected promises
      // from the above hooks. This can't prevent the thrown error
      // from propagating but can be used to redirect.
      error: function(reason) {
        router.transitionTo('login');
      }
    }

TODO
----

- Not sure what to do (if anything) about failure/loading handlers.
- README.md to document the API changes.
- Preparing Ember for this change