Dependency injection and inheritance

**I'm submitting a bug report**

* **Library Version:**
1.0.7

**Please tell us about your environment:**
* **Operating System:**
Windows 2016 Server

* **Node Version:**
6.9.4

* **NPM Version:**
4.1.1

* **JSPM OR Webpack AND Version**
webpack 2.1.0-beta.27

* **Browser:**
all

* **Language:**
TypeScript 2.1.5

**Current behavior:**
I don't know if this is a bug or me not doing it right.
Let's say I have this scenarion:
```TypeScript
export abstract class ViewModelBase{
model:any;
constructor(protected service: any){}
abstract save();
}

import {DataService1} from './dataService1';
@inject(DataService1)
export class ConcreteViewModel1 extends ViewModelBase{
constructor(dataService: Dataservice1){
super(dataService);
}

save(){
this.service.saveData(this.model);
}
}

import {DataService2} from './dataService2';
@inject(DataService2)
export class ConcreteViewModel2 extends ViewModelBase{
constructor(dataService: Dataservice2){
super(dataService);
}

save(){
this.service.saveData(this.model);
}
}
```

Now if I do this:
1. Open a composite which view-model is **ConcreteViewModel1**. it will instantiate the correct view-model **ConcreteViewModel1** and inject the correct dependent service **DataService1**.
2. Call view-model **save**() it will call the correct one.
then..
3. Open a composite which view-model is **ConcreteViewmodel2**. It will again instantiate it correctly.
4. Call view-model **save**(), it will call the **ConcreteViewmodel2.save()**.
But..
5. I again open a composite which view-model is **ConcreteViewModel1** and then
6. Call view-model **save**() it will throw exception because in the background it's service property is of type **DataService2** and it should be **DataService1**

**Expected/desired behavior:**

I expect that the injected service is the correct one.

* **What is the expected behavior?**
I expect that the injected service is the correct one.

* **What is the motivation / use case for changing the behavior?**
To abstract common stuff in a base class, and override the one's that changes in derived classes.

Start by reproducing the TypeScript example with ConcreteViewModel1, ConcreteViewModel2, DataService1, and DataService2, opening the composites in the order described. Trace Aurelia's dependency-injection and view-model construction entry points to determine why the service reference is retained; done means each view-model consistently receives its own service after repeated openings.

Written by the indexing model from the issue text.