Added length property to Ember.Map
Adds the ability to specify the view class used by the outlet Handlebars helper

Previous to this change, the view class used was always an "OutletView" (Metamorph extension of ContainerView).  This change allows the class to be set while still defaulting to the OutletView
Events sent to controllers can bubble

If you return true from an event handler on a controller, it
will continue to bubble (presumably to the router).

This is part of `routeTo` work:
https://github.com/emberjs/ember.js/pull/2522

Also related, on the router.js side:
https://github.com/tildeio/router.js/pull/15
Revert "Merge pull request #2563 from ef4/render-optimization"

This reverts commit 082a9870b176113eada12ba71ed83dd9de2ed702, reversing
changes made to 68fc7fc08ef6d553b8e01c6972040be6e0655cd4.
This function is already defined as `set`
Remove unused helper function

`setAndFlush` is defined but not used.
Adding regression test
Remove IE specified test
Switch from delegate/undelegate to on/off for EventDispatcher.
Switch from bind to on for routing handlers.
Update rsvp to include rejection on resolver exception
Merge pull request #2590 from teddyzeenny/update-rsvp

Update rsvp to include rejection on resolver exception
Merge pull request #2589 from tricknotes/remove-ie-specified-test

Remove IE specified test
Merge pull request #2577 from machty/bubbling-controller-events

Events sent to controllers can bubble
Sync with router.js
Merge pull request #2591 from xtian/event-alias

Remove aliased jQuery event methods
Merge pull request #2592 from machty/routerjs-sync

Sync with router.js
Merge pull request #2588 from tricknotes/remove-unused

Remove unused helper function
Merge pull request #2587 from tricknotes/remove-duplication

This function is already defined as `set`
Make router's render idempotent

This change prevents us from tearing down and recreating a view when
the new view is functionally identical to the old view.

This has important benefits:

 - when you're changing context within a route, the view itself
   remains stable, and the controller has full control over how and
   when to update the data it's presenting to the view
   layer. (Previously, you got a forced re-render immediately whether
   you were ready for it or not.)

 - when you're changing between routes, you can decide to keep the
   prior view in place, and replace it later when you're ready. (Think
   animated transitions between routes.)

This supercedes the proposed changes in PR #2563 (which has already
been reverted).