Run Ember in node

This commit removes any strict dependencies on browser-only APIs.
Anything user agent specific (such as window, document, etc.) are
abstracted out into a new `environment` object.

Currently we feature detect whether a DOM implementation is available
and only enable certain behavior if so. The intent of the feature
detection is to determine if a DOM implementation is available, not
whether we’re running in the browser or in node. This makes it possible
to run Ember in a node environment with a “fake” DOM.

This commit also introduces some refactoring to the location APIs, such
that hardcoded document/history/navigator dependencies are reduced.

Note that some APIs are guarded with `environment.hasDOM` checks.
Code inside those guards can freely use DOM APIs, but some of those
APIs are needed for full server-side usage of Ember. This is a first
step that is designed to explicitly separate out code with DOM
dependencies from isomorphic code. Further PRs will implement the
Renderer and Location APIs for non-DOM environments.
@wycats Do you think anyone might be relying on us historically storing the history state? ala accessing `history.state.path`? `history.state` is stored to disk in most modern browsers and [restored on browser restarts](https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Manipulating_the_browser_history#The_pushState()_method) https://github.com/emberjs/ember.js/pull/2887#issuecomment-19959565