[FEATURE ember-metal-injected-properties] Injected properties

# Injected Properties

This PR is intended to implement the necessary features for Ember 'services' (see #4861). It introduces 'injection helpers' which are computed properties that are container-aware, but whose use is type dependent (e.g., you cannot define an injected controller property on a view). As discussed on @tomdale's PR, there is ambiguity between an injection helper named `Ember.controller` and the actual `Ember.Controller` class, so to avoid this I've created a new top level namespace called `inject` (see below).

As an example, the following is enabled:
```javascript
App.PostController = Ember.Controller.extend({
  posts: Ember.inject.controller()
});
```
Which is functionally equivalent to:
```javascript
App.PostController = Ember.Controller.extend({
  needs: 'posts',
  posts: Ember.computed.alias('controllers.posts')
});
```

This PR also adds the `controller` and `service` injection helpers (as well as `Ember.Service`), but those commits can easily be extracted into another PR

##  Validation

In order to enforce good practices, injection helpers can only be used with certain ember objects (or rather _can't_ be used with certain ember objects).

1. controllers can only be injected into other controllers
2. ~~services cannot be injected into views or components~~

This validation check can happen in one of two places:

1. at mixin time
2. at instantiation time

The first option seems better since it happens early and only once.

A second type of validation ensures that the object with injection properties has a reference to the container, and that the container has knowledge of the requested injections (through `app.register` or the resolver). This check can happen at one of two places:

1. at instantiation time
2. at access time

The first option seems better since it happens earlier (assuming that registration of container types happens during app bootstrap).

##  Injection

When an injection helper property is declared on a class, all instances of that class need the property looked up and set. There are a few places this can happen:

1. at instantiation time via normal container injection
2. at instantiation time in `CoreObject`
3. lazy lookup on container in computed property getter

The first option would maintain consistency with current container injections and allow instances to access their properties without calling `.get()`, but require either accessing the injection at mixin time (where a container is not currently accessible), or by altering the container to be aware of the ember object model (which it is currently only vaguely aware of). The last approach has the advantage of not performing a lookup if never accessed, and being able to take advantage of CP cache, which seems to make it the best candidate.

## Design Decisions

### Feature name

This touches more than just `ember-metal`, but that package is the lowest common denominator. It would be trivial to split this up into multiple dependent features as an alternative.

### `inject` namespace

This is simply to avoid the potential ambiguity between `Ember.controller`/`Ember.Controller` `Ember.service`/`Ember.Service`. It also happens to read well, since what the developer wants to do is, for example, 'inject [a] controller'.

### `inject` namespace (not) as a function

Much like `Ember.run` and `Ember.computed`, the `Ember.inject` namespace could potentially be a convenience method for a container injection property, however that would enable the "injection of anything into anything" anti-pattern that should be avoided if possible. By only allowing injected properties through predefined methods, Ember is enforcing best practices.

### Referencing the container in ember-metal

The container is not mentioned anywhere in `ember-metal`, but since injected properties are type of descriptor, and all other descriptor properties are defined in `ember-metal`, it seemed like the best place. It could also easily go in the `ember-runtime` package.

### ~~Validation in `Ember.Object` `init` event~~ (no longer applies)

There are a few places instantiation-time validation can happen:

1. directly in `CoreObject`'s constructor
1. `Object`'s init` event/hook
2. `Object`'s `didDefineProperty` hook

Although nothing in Ember core (to my knowledge) currently uses the `init` event, it seemed like the best option since requiring _all_ existing subclasses that define `init` or `didDefineProperty` hooks call `_super` for validation to work, is IMHO dangerous and could be considered a breaking API change. Yes, controllers currently implement this check in the `init` hook, but extending it to all objects is much farther reaching.

### `willMergeMixin` on `Ember.Object`

This is obviously dubious for the potential performance hit. However, during my `ember-metal` spelunking, it seems like this private hook is specifically intended for doing any special mixin-time handling. So short of baking injected property validation into `ember-metal` itself, this is all I could come up with.

### Branding vs. `instanceof`

This is something that @stefanpenner mentioned in the original PR. I could not find much information on the performance implications of "branding" versus use of the `instanceof` operator, except by inference in this [jsperf](http://jsperf.com/instanceof-performance/2) (which only shows results in chrome). This did not seem to warrant breaking existing patterns, and can easily be changed later when other `instanceof` checks are converted.

### `Ember.assert` vs. `throw new EmberError(...)`

To be perfectly honest, I have no idea when something warrants a full production-time exception over a development assertion. Is there a guide for this anywhere? I ended up just making best-guesses.

### TODO

It should be possible to cache a list of injected properties on the constructor's meta object when mixin-time validation happens, thereby avoiding the repeated descriptor lookups at instantiation-time validation. I just don't know enough about how metadata is stored/accessed to be confident enough to do this, especially since there are additional considerations when classes get extended multiple times with new injected properties.

Insofar as the container is a self contained microlib, one could view this as a 'public' API, just like the `extend` and `create` methods. It seems strange that the container should look for a private method on the mostly-opaque objects that it encapsulates. I have no problem changing it, I just wanted to give my reasoning for naming it that way.