Add hooks to containerView.

It helps in some cases where we need to implement some special behavior
on outlet connection.
We add four new methods to containerView :
`presentCurrentView` and `dismissCurrentView`
`appendCurrentView` and `removeCurrentView`

In cases where we need some special handeling like animations you can
override theus methods

Add willAppear / willDisappear and didAppear / didDisappear

Refactor so it would be easier to override presentCurrentView / dismissCurrentView
Fix State.transitionTo to handle multiple contexts

Allows multiple contexts to be passed to Ember.State.transitionTo either as multiple arguments or as an array of contexts within an event.

Changed StateManager.send and sendRecursively to allow multiple context arguments.
Calling removeListener without method should remove all listeners
A listener registered with one can be removed with off
Fix for popstate firing on page load.
Remove ember-views dependency from ember-states

Ember-views is now an optional dependency for ember-states.  It is only required in the test file.
check if removed observer keeps firing
Remove ember-views dependency from test suite, stub the Event.

For the purposes of the test suite Ember.$.Event is required to exist.  We can just use an empty function rather than requiring all of ember-views.
Merge pull request #1354 from bestcroftington/master

Allow State.transitionTo handle multiple contexts
Fix trailing comma and whitespace
Remove dependency on `window` throughout Ember

Previously, Ember used the `window` object for
three concerns:

* `imports`: libraries that Ember requires in
  order to work, such as `jQuery`, `Handlebars`,
  and `Metamorph`
* `exports`: the variables that Ember itself
  exports (`Ember` and `Em`)
* `lookup`: the global lookup path for application
  code (e.g. when used in Handlebars templates).

Now, these three concerns are looked up on
`Ember.imports`, `Ember.exports` and
`Ember.lookup` respectively.

For convenience, all three of these are assigned
to `window` by default.

You can change the defaults by assigning a new
Ember object before loading Ember:

```javascript
var imports = {
  Handlebars: Handlebars,
  Metamorph: Metamorph,
  jQuery: jQuery
};

var exports = {}, lookup = {};

Ember = {
  imports: imports,
  exports: exports,
  lookup: lookup
}
```

You can use this to package Ember for external
module loaders like AMD:

```javascript
define("Ember",
  ["exports",
   "App",
   "handlebars",
   "metamorph",
    "jQuery"],
  function(exports, App, Handlebars, Metamorph, jQuery) {
    var imports = {
      Handlebars: Handlebars,
      Metamorph: Metamorph,
      jQuery: jQuery
    };

    var Ember = {
      imports: imports,
      exports: exports,
      lookup: { App: App }
    }

    // distributed ember.js
  });

define("App", [], function() {
  return {};
});

define("Post",
  ["App", "Ember"],
  function(App, Ember) {
    App.Post = Ember.Object.extend({
      // stuff
    });
  });
```

You can use a similar technique to package Ember
Runtime for Node or other environments with
CommonJS-style modules.
Merge pull request #1198 from tchak/container-view-hooks

Container view hooks
Merge pull request #1388 from tchak/events-off

Calling removeListener without method should remove all listeners
Merge pull request #1425 from ghempton/fix-popstate

Fix for popstate firing on page load.
Merge pull request #1440 from lihanli/remove-observer-test

Fix 'removing observer should stop firing' test
Allow extension of chosen prototypes instead of the current all or none.

One of my current projects involves embedding an ember widget into
a rather large pre-existing application   Extending the Array prototype
causes a slew of issues for both first party and third party code
in use on the relevant pages.

This change is backwards compatible and enables, via a new ENV hash,
the ability to choose exactly which prototypes to extend:

window.Env = {
    EXTEND_PROTOTYPES: true,
    PROTOTYPE_EXTENSIONS: {
    //  all: true,
        Function: true,
        String: true,
        Array: true
    }
};

Conflicts:
	packages/ember-metal/lib/core.js
	packages/ember-runtime/lib/ext/function.js
	packages/ember-runtime/lib/system/string.js
Fixed some documentation errors
Allow extension of chosen prototypes instead of the current all or none

One of my current projects involves embedding an ember widget into
a rather large pre-existing application   Extending the Array prototype
causes a slew of issues for both first party and third party code
in use on the relevant pages.

This change is backwards compatible and enables, via updating the
handling of the ENV.EXTEND_PROTOTYPES variable, the ability to choose
exactly which prototypes to extend:

window.Env = {
    EXTEND_PROTOTYPES: {
        Function: true,
        String: true,
        Array: true
    }
};

If window.ENV.EXTEND_PROTOTYPES is true or undefined
Ember.ENV.EXTEND_PROTOTYPES is initialized to the above hash.

If false it is initialized to the above hash with false intead of
true set for each prototype.

Otherwise it is assuemd to be a hash configured properly for the
application at hand.
Merge pull request #1449 from jdsmith2816/prototype-extensions

Allow extension of chosen prototypes instead of the current all or none.