Add Ember.on, Function.prototype.on, didInit event

This commit adds `Ember.on(eventName, func)` and `Function.prototype.on`
as cousins to `Ember.observes` and `Function.prototype.observes`. This
provides a declarative form of marking methods to execute when an event
fires.

This is useful for mixins which need to do things on `didInsertElement` and `willDestroyElement`, but don't want to force a call to `super` from the classes that include it:

    Ember.Mixin.create({
      doSomethingWithElement: function() {
        // Executes whenever the "didInsertElement" event fires, regardless of the presence of a method named `didInsertElement`
      }.on('didInsertElement')
    });

In addition, this commit also makes Ember.Object send a `didInit` event after initializing. This provides for an elegant solution to a common need: marking a function as an observer and also executing it at creation time. e.g.

    Ember.Object.extend({
      upateOptions: function(){
        var opts = this.get('controller.foo').importantTransform();
        this.set('options', opts);
      }.observes('controller.foo').on('didInit')
    });
Merge pull request #3155 from lukemelia/ember-on

Add Ember.on, Function.prototype.on, and didInit event
don't alter shape of meta object in ctor

thanks @eviltrout and @ebryn
Update LICENSE
Use a single array for actions.

Eliminate array creation for each listener added.
Fix Ember._suspendListeners

We need more tests around this code.
update s3 upload task and update Gemfile.lock dependencies

Stops the error of "ember.prod.prod.js" not found on Travis, and also
updates the Gemfile to use the new gzip stuff for uploading to s3.
Merge pull request #3164 from fivetanley/new-s3-config

update s3 upload task and update Gemfile.lock dependencies
Avoids Ember.Logger.assert unless needed

It seems console.assert tends to cause some deoptimizations, leading to
some poor performance in development ment. So lets just avoid that
code path unless needed.
Merge pull request #3174 from stefanpenner/master

Avoids Ember.Logger.assert unless needed
supporting replaceURL on HashLocation
Change didInit event to just init
Factory Injections

Each now uses container.lookupFactory to fetch the correct
'controller:array' factory

container gets factory injections

You are now able to inject on to factories:

```javascript
container.register('model:user', User);
container.register('store:main', Store);
container.register('config:main', Config);

container.factoryInjection('model:user', 'store', 'store:main')

container.injection('model:user', 'config', 'config:main')

container.lookupFactory('model:user').store === instanceof Store;
```

Also the factory returned from `container.lookupFactory` can be used
to instantiate fully injected instances.

```javascript
// assuming the above example

var UserFactory = container.lookupFactory('model:user');

var user = UserFactory.create({ name: 'stefan' })

user.container === container // => true
user.config instanceof Config // => true
```
aliased xProperty methods in enumerable to xBy and aliased some and someProperty to any and anyBy respectively
Merge pull request #3158 from michaelcrismali/master

renamed findProperty to findByProperty since that's what it's doing
Fix typos in Ember.Enumerable deprecations
Merge pull request #3178 from mmun/fix-typos

Fix typos in Ember.Enumerable deprecations
remove 2 year old undocumented behavior
Change behavior around uncached computed properties.

1. Dependent key changes are only observed after
   a computed property has been consumed, and only
   trigger a change event when invalidating the
   cache.

2. Observing a path will not consume uncached
   computed properties.

3. Calling set directly on the computed property
   will still cause a change event (outside of init)
   and set the cache.

This forces CPs to be used as properties rather
than as convoluted way of adding observers to
dependent keys, reduces the event churn caused by
observing paths, and makes unused computed properties
not cost anything.

Example:
```html
<p>{{fullName}}</p>
```

```javascript
fullName: function () {
  return this.get('firstName') + ' ' + this.get('lastName');
}.property('firstName', 'lastName')
```

In this example, sets to `firstName` or `lastName` will
not cause changes to `fullName` until the template is rendered.
After being rendered, only the first set to a dependent key will
cause a change, until the template consumes `fullName` again when
it updates its binding.

Example:
```html
<p>{{authorName}}</p>
```

```javascript
authorName: function () {
  if (this.get('isLoaded')) {
    return this.get('author.name');
  }
}.property('isLoaded', 'author.name')
```

In this example, before this change just observing
`authorName` would consume `author` via the `author.name`
dependent key and after this change `author` will
not be consumed until `isLoaded` is true.

Notes:

If you were scheduling the initial consumption of
a CP via an observer and were not calling this observer
on init but relying on the dependent key set to kick
off initial work, you need to call that observer
on init.

For example, if `selection` is a computed property:

```javascript
selectionDidChange: function () {
  Ember.run.once(this, 'setupSelection');
}.observes('selection'),

setupSelection: function () {
  var selection = this.get('selection');
  // do work with selection
}.on('init')
```

This is good form regardless of it being a computed
property since properties set on `create` do not
trigger observers.
Merge pull request #3021 from stefanpenner/factory_injections

Container Learns: Factory injections