[DOC beta] Fix sample code for `Ember.Handlebars.registerBoundHelper`

This has been noted by the sharp eyes of @ZenCocoon in http://git.io/rIuURA.
Update to Ember.View's attributeBindings Documentation

You can map one property on to another within the `attributeBindings` array, but this wasn't represented in the documentation. I talked about this with @rwjblue in #emberjs yesterday, and he recommended I update the docs. :smile:
[BUGFIX beta] Does not disregard currentWhen when given explicitly.
FIxes #4688
always set a controllers `model`

see: https://github.com/emberjs/ember.js/pull/4293#issuecomment-40490527
[DOC release] Remove private wording from makeBoundHelper.

This function is required when storing helpers in the container.

Specifically, in ember-cli (or EAK/EAKR) you would need to use
`Ember.Handelbars.makeBoundHelper` in your helpers default export.

Something like the following is needed (in `app/helpers/up-case.js`):

```javascript
export default Ember.Handlebars.makeBoundHelper(function(value) {
  return value.toUpperCase();
});
```

The current "private" verbiage is misleading, and this should be a
normally supported use case.
Complete set of failing tests.
SortableMixin doesn't currently work if sortAscending and sortProperties are set at the same time.
Failing tests either copied from or based off of https://github.com/emberjs/ember.js/pull/3422
Invalidate previous sorting if sortProperties changes.
[BUGFIX feature] Ensure that AutoLocation gets `rootURL` as an option to `create`.\nFixes #4704.\n\nAutoLocation makes decisions about replacement URLs that depend on the `rootURL` setting of the router, but the router was only providing the value of `rootURL` after `AutoLocation.create` was already called, making it not respect the `rootURL`.\n\nTo fix this issue, this commit introduces a `settings` injection type.  This type is private for now. The `root-url` setting is either `null`, the default, or a string value taken from the public API of `Router#rootURL`. `settings:root-url` will be injected as `rootURL` in all objects of `location` type.
[BUGFIX feature] Assert rootURL has trailing slash when used with AutoLocation + additional test coverage
[BUGFIX beta] sync router.js; closes #4535
The example of extending Ember.TextField with required is not relevant anymore

Since the `required` attribute is part of the recognised attributes as listed on line 27, the example about extending Ember.TextField shouldn't be about extending with `required`.

However I am under the impression that default "coming soon" behaviour is to accept all attributes by default instead of specifying them. If that's the case the whole Extension paragraph might be irrelevant.
[DOC release] Add reference to Ember.String.loc for {{loc}} helper so you can actually learn how to use it
[BUGFIX beta] Properly resolve helpers from {{unbound}}.

Prior to this referencing a helper that would normally need to be looked up with
the `{{unbound}}` helper would not work.

This meant that you could not use helpers that are stored in the container.

This commit fixes that issue.
[BUGFIX beta] Sync router.js, closes #4399, retry() bug
[BUGFIX beta] Sync router.js, get rid of derelict async hook

Conflicts:
	packages_es6/ember-routing/lib/vendor/router.amd.js
[BUGFIX beta] Normalize the `if` and `bind-attr` truthiness

Changelog updated

Conflicts:
	CHANGELOG.md
[DOC release] Fix typo "if" -> "it"
Revert "[BUGFIX beta] Total invalidation of arrayComputed by non-array dependencies should be synchronous"

This reverts commit 7af8beb0bb9e484ab7427b447f6b6dbb76b4aad8 which attempted to
bring the semantics of ReduceComputedProperty closer to those of ComputedProperty
but inadvertently introduced a performance regression in some cases.

ComputedProperty guarantees that any `set` calls that occur before a `get` call
will be run before the `get` call is triggered. For example

```javascript
var obj = Ember.Object.extend({
  foo: Ember.computed.alias('bar')
}).create();

obj.set('foo', 1);
obj.get('foo'); // returns 1
```

For technical reasons ReduceComputedProperty does not offer the same
guarantees.

```javascript
var obj = Ember.Object.extend({
  filtered: Ember.computed.filter('things', function(n) {
    return n % 2 === this.get('parity');
  }).property('things', 'parity')
}).create({
  things: [0, 1, 2, 3, 4, 5]
});

o.set('parity', 0);
o.get('filtered'); // returns [0, 2, 4]

o.set('parity', 1);
o.get('filtered'); // returns [0, 2, 4], but we expected [1, 3, 5]

Ember.run.next(function() {
  o.get('filtered'); // returns [1, 3, 5]
});
```

The commit fixed this issue but introduced a performance regression. Every call
to `set` would eagerly force a recomputation of the reduced computed value,
instead of deferring the work until a subsequent `get` call. This was seen
most prominently in Ember.computed.sort with sortProperties that changed
quickly. You can find more details about the regression at:

https://github.com/emberjs/ember.js/issues/4712
https://github.com/emberjs/ember.js/issues/4740

Conflicts:
	packages_es6/ember-runtime/tests/computed/reduce_computed_test.js
[DOC] Clarify where a controllers `target` property gets defined

The previous documentation was correct but still required a little
digging to find the actual place where the injection is defined.