["BUGFIX" beta] Improve unhandled action error messages

1) The comment about `return true` being a possible source of error
   is incorrect; even if an action handler returns true, the action
   is considered handled and it won't cause an error even if parent
   routes don't handle the event.
2) 99% of the time, the only time people see the error about no
   active handlers is when they try to call `Route#send` within
   `model`, `beforeModel`, or `afterModel`. Most likely the solution
   is to call `Transition#send` on the transition object passed into
   the various model hooks, so I've updated the error message
   to suggest using `Transition#send` instead.
Updated the docs for Ember.Route.activate() to show that it happens on every enter, and not just the first time.
[BUGFIX beta] Bubble `loading` action above pivot route

This is for the `ember-routing-loading-error-substates`
feature. The `loading` action will now always bubble
to `ApplicationRoute`; the logic for preventing substate
entry into a substate above the pivot route has been
moved default action handlers that live "above"
`ApplicationRoute`. /cc krisselden
[FEATURE ember-router-named-substates] Prefer named substates

- When looking for an appropriate substate to enter, the router will
first try and find a loading substate sibling with the name of
router that the error/loading action emanated from, e.g. if foo
route returns a slow promise and both foo_loading and loading
routers have been defined (via route class or template), the
foo_loading substate will be preferred and entered over plain ol'
loading, whereas a slow promise from 'bar' route would enter
the more generalized 'loading' route (assuming 'bar_loading' route
wasn't defined)

- Top-level error/loading substates can now be entered. They are
top-level, which means they get rendered as siblings to
ApplicationView vs within ApplicationView's outlet. This
handles slow/rejecting promises returned from ApplicationRoute.
If a route class/template corresponding to 'application_error'
or 'application_loading' is found, it will be entered. This
may seem like a special-casing of the substate naming conventions,
but is actually consistent with the useful rule established in
(2) above: Ember will say "ok, slow/rejecting promise came from
the 'application' route, let's check if a specifically named
'error' or 'loading' substate exists for it and enter it if so".
The only special-casing is that it won't go to the second step
of generalizing and looking for routes named specifically
'loading'/'error' to enter, since that corresponds to child
substates of the internal this.resource('application')
Merge pull request #3655 from machty/substates-enhancements

[FEATURE ember-routing-loading-error-substates] Named substate entry
Merge pull request #3677 from SinisterMinister/master

Updated the docs for Ember.Route.activate()
Merge pull request #3656 from machty/better-action-errors

["BUGFIX" beta] Improve unhandled action error messages
Add tests to ensure EXTEND_PROTOYPES is honored.
Merge pull request #3678 from rjackson/fix_prototype_assertions

Add tests to ensure EXTEND_PROTOYPES is honored.
[BUGFIX beta] Allow test helpers to be injected on specific object.

This allows the test helpers to be injected into an object other than
`window`.
Merge pull request #3686 from rjackson/refactor_testing

[BUGFIX beta] Allow test helpers to be injected on specific object.
Remove inconsistent global reference to Handlebars in helper
Merge pull request #3688 from kumavis/master

Fix typo in Handlebars