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.

lets destroy after its been removed, this way if destroy errors we don't have a corrupted cache. (this likely barely matters ...)