patch for url encoding/decoding issue (#3263)

This PR normalizes browser inconsistencies regarding the encoded / decoded properties on the `window.location` object. As discussed in #3263, it force-url-decodes all properties prior to using them, and force-encodes all properties prior to setting them, and prior to using them for internal comparison.

The edge case that this PR cannot solve is the literal `%25`. Given an unknown browser behavior on the input being url encoded or decoded, we have no way of knowing, for sure, whether it means `%` (originall encoded) or `%25` (originally decoded). There is no behavior-sniffing method, that I know of, to check whether a browser would url-encode / url-decode in a given situation, and @wagenet has expressed a desire not to use browser-sniffing code in the ember code base with regards to this issue. ([here](https://github.com/emberjs/ember.js/issues/3263#issuecomment-25736757))

Tests: none for now. The code needs review to check for expected correct API, i.e. where to return a url encoded/decoded strings.

This PR might also necessitate changes in downstream code that consumes the location api, e.g. it should render #3396 obsolete.

This PR *might* cause BC-breaks to apps that rely on some location-api-derived apis, e.g. the `params` hash in routes' `model` hook, being at the current form (undefined behavior depending on browser).