Drop dead code for * in paths

The only guidance I can find on using `*` in paths has [just been removed](https://github.com/emberjs/ember.js/pull/4624/files#diff-a2a8793237eb99624784efe1d784df4eL50). And that example did not work on the console anyway. The `*` was used in Sproutcore for "Chained Property Paths":

http://guides.sproutcore.com/core_concepts_kvo.html

> Observers are able to use a special type of property path called a +chained property path+. When using an observer (or a binding as we will see), usually the actual observer is only added to the second to last object in the property path. Therefore, if you add an observer for the path "MyApp.usersController.mainUser.name", SproutCore finds the object at "MyApp.usersController.mainUser" and adds the observer to its name property. In this case, nothing is observing MyApp.usersController to see if its mainUser property changes.
>
> What we want to do is watch for changes to usersController.mainUser and for changes to mainUser.name. This is where chained property paths come in. To let SproutCore know that we want observers on both, we use a chained property path like MyApp.usersController*mainUser.name.
>
> The asterisk (*) in the property path indicates that we want SproutCore to observe changes to all properties following the asterisk. In this case, that is both mainUser and name.
>
> So why don't we always use chained observers? Observers are "expensive", they take time to set up and they have to run each time their properties change and often times we don't have changes in all levels. In the previous example, we don't care about changes to MyApp.usersController, because we are never going to replace it. If the same were true for mainUser, we wouldn't want to observe it either. Therefore, it is advisable in practice to use chained observers as little as possible, in order to protect performance.

Which is a type of observed path that Ember itself does not distinguish. I propose removing this cruft, especially in light of discussions like #4619 where alternative uses for `*` are being discussed.