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.

I discussed the need for a session-specific registry that could fall back to the general app registry with @wycats and @tomdale. The rationale is that some usages, like A/B testing, might require a registry per session (in practice this registry would be close to empty). The `Session` could then expose a `register`, which would apply to the session-specific registry.

Anyway, I will fix up the tests to avoid accessing `container._registry`. As I said above, this was sloppy refactoring during the change from `container.registry` to `container._registry`.