fix($location): allow hash fragments with hashPrefix in hash-bang location urls

Previously if there was a hash fragment but no hashPrefix we would throw an error.
Now we assume that the hash-bang path is empty and that the hash is a valid fragment.

This prevents unnecessary exceptions where we clear the hashBang path, say by
navigating back to the base url, where the $browser leaves an empty hash symbol
on the URL to ensure there is no browser reload.

BREAKING CHANGE:

We no longer throw an `ihshprfx` error if the URL after the base path
contains only a hash fragment.  Previously, if the base URL was `http://abc.com/base/`
and the hashPrefix is `!` then trying to parse `http://abc.com/base/#some-fragment`
would have thrown an error. Now we simply assume it is a normal fragment and
that the path is empty, resulting `$location.absUrl() === "http://abc.com/base/#!/#some-fragment"`.

This should not break any applications, but you can no longer rely on receiving the
`ihshprfx` error for paths that have the syntax above. It is actually more similar
to what currently happens for invalid extra paths anyway:  If the base URL
and hashPrfix are set up as above, then `http://abc.com/base/other/path` does not
throw an error but just ignores the extra path: `http://abc.com/base`.

Closes #9629
Closes #9635
Closes #10228
Closes #10308