Initial application load presents incorrect binding context for a submodule of a module that has it's own routes

**I'm submitting a bug report**

* **Library Version:**
* bootstrapper: `^2.0.1`
* framework: `1.0.8`

**Please tell us about your environment:**
* **Operating System:**
Windows 10

* **Node Version:**
7.7.3

* **NPM Version:**
4.1.2

* **JSPM**
JSPM 0.17.0-beta.42

* **Browser:**
Chrome 59 (no other supported browser supports Shadow DOM)

* **Language:**
ESNext & TypeScript

**Context:**
An app `MyApp` has a route, `module`, that is handled by `MyModule`. `MyModule` has a route, `sub` that is handled by `MySubmodule`.

**Current behavior:**
If the user initially navigates to (loads the app at) `#/module/somethingelse` and then later navigates to `#/module/sub`, `MySubmodule` is rendered using the correct bindingContext/overrideContext. If the user initially navigates to `#/module/sub`, `MySubmodule` is rendered using an overrideContext that has no parent, resulting in any properties defined on `MyModule` or `App` being completely inaccessible.

**Expected/desired behavior:**
`MySubmodule` is rendered using a bindingContext/overrideContext that has access to all of the expected parent override contexts (e.g. those for `MyModule` and `App`).

**Failure mode:**
If the user initially navigates to `#/module/sub`, `MySubmodule.bind()` is called before `RouterView.bind()` is called for the `` of `MyModule`. Because of this, when the submodule is bound, the router view's override context property has not been set, thus the submodule is bound with a virgin override context that has no parent override contexts. If the user initially navigates to another route, and then later navigates to the submodule, `RotuerView.bind()` has been called, thus its override context has been set, thus the submodule is bound with that override context (granted, the route that is initially navigated to will have the binding issue).

`RouterView.process()` calls `RouterView.swap()`, which calls `Controller.automate()` (passing it's override context), which calls `Controller.bind()` which calls `View.bind()` which calls `MySubmodule.bind()`. Thus this boils down to the `` of `MyModule` being processed before it is bound, which seems to be related to the pipeline of `MyModule`'s router and possibly the pipeline of `App`'s router.