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.
ok, thats fine. We should hammer out what the path is soon then.
we should sill should annotate this renderer to clearly be the deprecated one, maybe via `toString`