[DOC beta] Document Ember.Route #controllerName and #viewName properties.
[BUGFIX beta] Remove false attribute from Ember.View

In IE8 (or older), `jQuery.fn.prop` always update DOM against our
expectation.(This is a jQuery bug but it couldn't fix)
ref: http://bugs.jquery.com/ticket/13558

So the following test is failed due to `view.$().attr('foo')` returns `"false"`.:
* https://github.com/emberjs/ember.js/blob/a449d445/packages/ember-views/tests/views/view/attribute_bindings_test.js#L126

To avoid this issue, `removeAttr` should be called when `null`, `undefined` or `false` is given as value.

But this way contains incompatible changes:

Before:
``` javascript
view.set('checked', false);
view.$().prop('checked'); //=> false
```

After:
``` javascript
view.set('checked', false);
view.$().prop('checked'); //=> undefined
```
Don't call toString at extend time

Doing so will memoize the function so that any Ember.View subclass will return the same value for toString.
Update VERSION post-release.
[FEATURE ember-routing-drop-deprecated-action-style] Enhanced actions

This satisfied #3808
[DOC release] Show RSVP.Promise preamble.
Merge pull request #4068 from bcardarella/bc-flag-for-deprecating-actions-behavior

[FEATURE ember-routing-drop-deprecated-action-style] Enhanced actions
Merge pull request #4101 from rjackson/fixup_rsvp_docs

[DOC release] Show RSVP.Promise preamble.
[Bugfix release] [fixes #4102] templates component properties should not collide with internal properties.

@stefanpenner / @kselden
Merge pull request #4103 from stefanpenner/fix_templateless_components

[Bugfix release] [fixes #4102] templates component properties should not...
[BUGFIX beta] Allow Ember.computed.sort to use property paths in sortDefinitions.

'Ember.computed.sort' 'works only if sortDefinitions contain simple properties.
It will fail if a `sortDefinition` contains a property path (i.e. something
like `person.name`).

A `SearchProxy` is used to shadow the new value of an underlying property with
the old value to ensure proper comparisons take place while searching for an
item in the sorted array. When using a property path rather than a simple
property to sort on, `SearchProxy` will use the actual property path in its
attempt to shadow underlying properties - something like: `{ person.name: 'John
Doe' }`. This causes things to blow up because every comparison between an
existing item `get(itemA, sortProperty)` and a SearchProxy `get(itemB,
sortProperty)` will return a bogus result. In this case, `get(itemB,
'person.name')` will not return the shadowed value (stored as `{ person.name:
'John Doe' } `) but rather the current value of that path on the proxy's
underlying `content`.

This commit allows a proper comparison to take place when a sortDefinition
contains a property path.
[Bugfix beta] improve action without actions hash deprecation warning
[FEATURE ember-metal-is-blank]
Merge pull request #4049 from efigarolam/master

[FEATURE] isBlank method for filtering whitespace strings
[BUGFIX] Create _super when applying mixins. Use __nextSuper in wrappers

This sets _super on the context of all Ember objects, and also sets _super
on mergedProperty contexts if they have a property that is a function.

Fixes #3523, discussed in #3683
[BUGFIX release] Reduce read-only calls to meta
[BUGFIX release] Pass meta into watchKey when possible
[BUGFIX release] Reduce even more meta calls by passing it along in other places
[BUGFIX release] Reduce even more meta calls by passing it along in other places (doh, missed one)
[BUGFIX beta] fixed issue with transition.resolvedModels

Already-resolved parent models weren't showing
up in modelFor hook post-refactor

cc @wagenet