[BUGFIX] HashLocation no longer assumes any hash is a route, uses forward slash prefix convention #/foo

Up until this PR, `HashLocation` returns `#foo` => `foo` as the "url" when the router asks for it, which means any hash gets considered by the router as a possible route. This prevents you from linking to element's with id's, like `<div id="foo">` as well as using normal `<a href="#foo">` in your app will incorrectly try to transition the app to a `foo` route. Also--If someone relies on this bug, it has the negative effect of causing duplicate history states if someone clicks a link to that same route inside the app since `#/foo` and `#foo` aren't the same URL, but resolve to the same route.

This bug has been [reported in the wild](https://stackoverflow.com/questions/16164566/section-links-with-ember-js).

This PR is also needed as part of a bigger solution to support auto-scrolling to id after route's finish transitioning to mimic the default browser behavior.

Related: https://github.com/emberjs/ember.js/issues/4098#issuecomment-59674832

Because this has existed since day one, I realize some people may unfortunately be relying on it for some reason...If we want to continue to support this behavior until 2.0, we can put this correction behind some sort of property flag that users can opt-into. e.g. `Ember.ENV.STRICT_HASH_LOCATION = true` or something. It might be worth noting that `AutoLocation` [didn't make this assumption](https://github.com/emberjs/ember.js/blob/master/packages/ember-routing/lib/location/auto_location.js#L275).

p.s. this also adds much needed tests for `HashLocation` in general. woot.
I think we should default to `Ember.$` not `jQuery` (after `import Ember from 'ember-meta/core';`).