[FEATURE] Support target attribute for `link-to` helper
[BUGFIX beta] Sync router.js, closes #4399, retry() bug
Merge pull request #4736 from machty/router-context-fallback

[BUGFIX beta] Sync router.js, closes #4399, retry() bug
[BUGFIX beta] Sync router.js, get rid of derelict async hook
Merge pull request #4739 from machty/omg-query-params-are-done

[BUGFIX beta] Sync router.js, get rid of derelict async hook
[BUGFIX beta] Normalize the `if` and `bind-attr` truthiness

Changelog updated
Merge pull request #4718 from selvagsz/feature_support_target_attribute_for_linkto

[FEATURE ember-routing-linkto-target-attribute]
Merge pull request #4662 from selvagsz/normalize_if_and_bindAttr_truthiness

[BUGFIX] Normalize the `if` and `bind-attr` truthiness
[DOC release] Fix typo "if" -> "it"
Merge pull request #4750 from bantic/master

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
Merge pull request #4753 from mmun/fix-4740

Revert "[BUGFIX beta] Total invalidation of arrayComputed by non-array d...
[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.
Merge pull request #4756 from praxxis/clarify_controller_target_injection

[DOC] Clarify where a controllers `target` property gets defined