fix($browser): don’t use history api when only the hash changes

IE10/11 have the following problem: When changing the url hash
via `history.pushState()` and then reverting the hash via direct
changes to `location.href` (or via a link) does not fire a
`hashchange` nor `popstate` event.

This commit changes the default behavior as follows:
Uses `location.href`/`location.replace` if the new url differs from
the previous url only in the hash fragment or the browser
does not support history API.
Use `history.pushState`/ `history.replaceState` otherwise.

Fixes #9143
Closes #9406
fix($browser): don’t use history api when only the hash changes

Fix jshint error
fix($browser): don’t use history api when only the hash changes

Fixes a failing test on IE9 caused as a side effect
of 404b95fe30a1bcd1313adafbd0018578d5b21d3d being merged
before 0656484d3e709c5162570b0dd6473b0b6140e5b2.

The test should have been independent on the browser running it
and it is now.

Closes #9423
Closes #9424
fix($browser): Cache `location.href` only during page reload phase

Adds caching for url changes while a reload is happening,
as browsers do not allow to read out the new location the browser
is navigating to.

Removes unnecessary caching from $browser, as IE7-IE9 all
have the new hash value in `location.href` after changing it.
There was a wrong assumption in the previous version of this code
introduced by dca23173e25a32cb740245ca7f7b01a84805f43f and d70711481e6311c9cd283d650f07ca0cca72ecc2.

Adds more tests for #6976
Fixes #9235
Closes #9470