[Bugfix Beta] Improve Ember.Map

* [Perf + ES6] no longer clone array before enumeration (dramatically reduce allocations)
* [Perf] Don’t rebind the callback of forEach if not needed
* [Perf + ES6] no longer allow Map#length to be bindable
* [Perf] don’t double guid keys, as they are passed from map to ordered set (add/remove)
* [ES6] deprecate Map#remove in-favor of the es6 Map#delete
* [ES6] error if callback is not a function
* [ES6] Map#set should return the map. This enables chaining map.`map.set(‘foo’,1).set(‘bar’,3);` etc
* [ES6] remove length in-favor of size.
* [ES6] throw if constructor is invoked without new
* [ES6] Make inheritance work correctly
[BUGFIX release] Cleanup ES3 Object.keys
Conflicts:
	packages/ember-runtime/tests/system/object/create_test.js
[BUGFIX release] fix finishChains for all chains that reference an obj not just the ones rooted at that object.
Adding dir and lang to allow for easier bidirectional support
Add note to CHANGELOG about new didInsertElement functionality

#5631
Update documentation of Ember.View didInsertElement hook, and add test to validate this behaviour.
Remove repeated "esnext" jshint rule
[BUGFIX beta] Fixes V8 bailouts for `propertiesFromHTMLOptions` function

Before:

![bailouts](https://cloud.githubusercontent.com/assets/1131196/4175916/51e9079c-35ec-11e4-9de0-a83abb8c2c22.png)

After:

![bailouts-fix](https://cloud.githubusercontent.com/assets/1131196/4175920/6b51211a-35ec-11e4-9423-271910496a9c.png)

Bailout reason: "ForIn is not fast case"

It turns out that we can use `Object.keys` instead of using `for-in`.

`for-in` is actually more expensive as it will enumerate properties in
the prototype chain as well (you have to use `hasOwnProperty` check
which is not cheap). More about
[`for-in`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/for...in)
for the curious.

`Object.keys` will return an array of a given object's own enumerable
properties. That is very handy because we can avoid `hasOwnProperty`
check and looking up properties on the prototype chain.

```javascript
var a = { bar: 'foo', baz: 'blah' };
Object.keys(a);
// ["bar", "baz"]
Object.getOwnPropertyDescriptor(a, 'bar');
// Object {value: "foo", writable: true, enumerable: true, configurable: true}
```

Conflicts:
	packages/ember-handlebars/lib/helpers/view.js
[BUGFIX beta] Update router.js.
[BUGFIX beta] Update metal view test helpers to work in IE8
[BUGFIX beta] contextualElements, handle omitted start tags

Also bumps HTMLBars.

During a renderTree call, look to the morphs for information about the
contextualElement. Pass this to the Ember renderer, which in turn passes
it to the buffer for use when generating an element.

Additionally, strip omitted start tags even if the child node causing
their generation is after a script tag. See the long comment in
`render_buffer`.

Conflicts:
	packages/ember-views/lib/system/render_buffer.js
[BUGFIX beta] Fix several test that fail due to bad DOM construction on IE8
[Bugfix beta] slightly defensive perf

Ember.merge is global and as such if merge(x, y) ever happens where y is not safe for enumeration, it can deopt the function (in v8) for all other users.

Since functions are shared, deopting merge can cause inlining bailout cascades throughout the framework. Now it is still possible to deopt it by for example passing a global like window to it, but at least it wont happen more unexpectedly.
[DOC release] Array mixin cleanup

Conflicts:
	packages/ember-runtime/lib/mixins/array.js