Inject Renderer instead of hardcoding constructor

Previously, an instance of `Renderer` was created and added to the
`CoreView` class. The top-level view to be rendered would look up this
`Renderer` via `this.constructor.renderer`, then pass it to the
child views as needed.

In anticipation of server-side rendering, this PR uses an injection to
provide the default DOM renderer to views directly via an injected
`renderer` property.

In light of the fact that historically many views were created without
going through the container, this implementation detects when a
renderer has not been provided (likely because someone called
`Ember.View.create()` manually) and hardcodes a fallback to the DOM
renderer.

Going forward, users (including Ember internally) should always
instantiate views via a looked up factory rather than calling it
directly. Non-containerized views will not work in a non-node
environment.

As a side-effect of putting the renderer into the container, we
discovered that it contained a `destroy()` utility method that was
being called by the container, thinking it was the standard Ember
method for destroying an object.

We have renamed this method to `removeAndDestroy()` and have updated
all of the tests that call the old method.
i believe this requires a larger discussion to understand the intent of multiple renderers