Decouple Registry from Container

This PR separates the current `Container` into stateless and stateful components:

* `Registry` - used for stateless factory / option registrations
* `Container` - uses a `Registry` to lookup factories and options, and then instantiates and caches objects itself

This decoupling is one of the infrastructure changes required to support server-side rendering, as outlined in #9938. It allows for multiple containers to reference a common registry, which is key to allowing a single Ember app to support multiple sessions. Other benefits include a cleaner separation of concerns and improved testing performance, since only container state should need to be reset between most tests.

In this first PR, an application is configured with a single registry and a single container. The registry is passed to initializers instead of the container, since initializers should be performing registrations instead of looking up instances. 

Subsequent work, which I'm coordinating with @tomdale and @wycats, will involve the introduction of a `Session` object. A single App will be able to support multiple sessions, each of which will cache data in a single container. A session initialization process will be introduced that parallels the App initialization process.

### Backward compatibility 

`Registry` is made backwards compatible by tracking the first instantiated container, and exposing its `lookup` and `lookupFactory` methods. Calls to these methods are deprecated, but it's important to allow them to avoid breaking initializers that rely upon them. 

`Container` is made backwards compatible by exposing many of its associated registry's methods. These methods are all deprecated.

### Removal of subcontainers

The concept of subcontainers (i.e. parent / children containers) was removed as part of this refactoring. It was a legacy feature that's no longer used within Ember core and has never been publicly documented, so it should be safe to remove without deprecation.

Yeah, I didn't re-examine this during the refactor, but that would be more efficient.