Improved test harnesses.

Although ember has pretty good architecture that facilitates 
good testing, for some things such as components and ember data models,
it can be tricky to figure out how to even get started testing.

Within ember apps, we tend to use context specific naming conventions
such as this.store(<model-name>), or needs[ <controller-name>], why do
we need to change this convention for our testing.

Also, although QUnit provides a battle tested testing framework
some conventions are pretty bar bone. Async testing, management of
test run specific properties, all leave much to be desired.

Async testing:

currently, patterns such as the following might be possible.

```js
test("foo", function(){

  stop();
  somethingAsync().then(function(){
    start();
    ok(true, '');
  });
})
```

But what if simply returning a promise to the callback
handled the start/stop/timeout book keeping for us?

Bonus: what if when the test framework detected a returned
promise, it also asserted that it must settled fulfilled.

```js
test("foo", function(){
  return somethingAsync().then(function(){
    ok(true, 'something important');
  });
})
```


Variables that are maintained for us, as per test lifecycle

testing various components

extensibility.