first draft of namespaced resolver proposal

Contains basic proposal that would be an opt-in and not break with any current (or future) app if implemented.
An app could even be made to have multiple resolvers in a chain (`Ember.MultiResolver`), using one as primary and one or more as fallback strategies (useful when migrating from one strategy to another or when mixing code from projects using different naming strategies...) 

On another note, it would be cool to use the same approach as for Resolver, so as to have both a `Ember.Route` and `Ember.DefaultRoute`, with the default setup being that `Ember.Route` simply is an alias (pointer to) `Ember.DefaultRoute` but allowing `Ember.Route` to be overridden while still preserving the default functionality... but I guess this could also be achieved simply having `App.Route` extending from `Ember.DefaultRoute`.

Same approach for Controller, View etc. This opens up a lot of new possibilities :)

Also, if we have convention like `App.Routes.Mixins` and `App.Routes.Abstract` the should live in folders `app/routes/mixins` and `app/routes/mixins`

Using such a convention, we could simplify mixin-in multiple mixins like this

```
// cumbersome...
App.CommentView = App.Route.extend(App.Routes.Mixins.MyMixin, .App.Routes.Mixins.MyOtherMixin, {...})

// alternative
App.CommentView = App.Route.extend({...}).mixin(App.Routes.Mixins: ['MyMixin', 'MyOtherMixin'])

// or by convention, always assume using App.Routes.Mixins as scope for a Route
App.CommentView = App.Route.extend({...}).mixin('MyMixin', 'MyOtherMixin')
``` 

Too many ideas on this topic :)

Just discovered you can do:

`App.__container__.lookup('application:controllers').get(xxx)``

But I don't see that changing much. Still the current flat naming standard feels awkward and limiting.