[FEATURE ember-routing-loading-error-substates] Named substate entry

This PR augments substate behavior in a few ways:

1) `loading` actions don't stop bubbling at the pivot route and will
   continue bubbling up the route hierarchy; this doesn't change the
   behavior whereby loading substates won't be entered if they're
   above the pivot route, but rather just fixes the odd behavior
   of you not being able to catch `loading` actions on higher level
   routes.
2) 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)
3) 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')

This may or may not make sense to merge into beta but I wanted to
get some eyes on it before making a decision. If we decide this
doesn't belong in beta, I can add a new feature flag around the
behavior in (2) and (3), but (1) should definitely make its
way into beta.