[FEATURE] Support target attribute for `link-to` helper
[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...
[Bugfix beta] sync backburner

* no longer deopt during run-loop flush (due to usage of try/catch)
* workaround older IE's lack of "catch" in try/finally statement bug
[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
[FEATURE ember-routing-will-change-hooks] finer-grain transition hooks

Brought to you by @ef4, and demonstrated at his
EmberConf talk:

http://confreaks.com/videos/3302-emberconf2014-animations-and-transitions-in-an-ember-app

See this router.js PR for details:

https://github.com/tildeio/router.js/pull/89
[Bugfix beta] Namespaces are now required to start with uppercase A-Z. Lowercase namespaces were deprecated long ago, and scanning for them was causing issues on certain Android devices.
[DOC release] Fix doc for startRouting in ember-application
Merge pull request #4763 from keydunov/master

[DOC release] Fix doc for startRouting in ember-application
[BUGFIX beta] reduceComputed detect retain:n better.

Fix #4620.

reduceComputed tries to skip walking all observer contexts when an item property
changes if the current tracked array state is [retain:n].  However, this check
occurs while applying the operations.  If [delete:m retain:(n-m)] is applied,
when the retain operation is visisted it will have been updated to retain:n.

This commit updates the check so that retain:n is only checked for the *first*
operation.
Merge pull request #4761 from hjdivad/fix-4620

[BUGFIX beta] reduceComputed detect retain:n better.
[DOC] Update assertion texts for Ember.Resolver

In 7626bc81233f98c229bf9aba0b240f41ab279aff the `Ember.AbstractResolver`
has been renamed to `Ember.Resolver`, but the assertion texts where not
updated accordingly.