Bug: getURLWithoutQueryAndHash wrong if url's ? and # in wrong order
Bad hack to fix history system on ie9 and other old browsers.
The history mechanism is currently failing in ie9.

In particular, in ie9 the "statechange" event is not being triggered
when it should be (facet selection, viewpanel changes).  I have
therefore introduced the following hack: modified exhibit's
"statelistener" to also listen for the more old-fashioned "hashchange"
event.  However, to prevent "double counting", if a statechange event
is ever fired, then the listener for the hashchange event is turned off.

I've introduced the hack because I don't understand enough about the
history library jquery is using to make a more correct fixed.

The problem appears to be rooted in jquery.history.js , a library
for history management that is included in exhibit
(http://github.com/browserstate/history.js).  This library purports to
offer a uniform approach to history management on browsers both new
(which use the html5 "statechange" event) and old (which rely on an
older mechanism that tracks state view a fragment identifier in the url,
and a "hashchange" event that is triggered when the fragment changes).

Apparently the history library provides emulation, triggering the
"statechange" event even on old browsers.  This allows applications to
uniformly rely on the statechange event, even on old browsers.  Which
is what exhibit does: it rerenders whenever a statechange event is
triggered.

Except, it doesn't seem to be working as intended with exhibit on ie9.
ie9 is an old browser, so html4 emulation is used.  In the file
history.html4.js, the pushstate function engages in some mysterious
logic as it decides whether or not to actually trigger the statechange
event.  In particular, when invoked as a result of exhibit calling
pushstate,  it tests for (newStateHash !== html4Hash &&
newStateHash !== History.getShortUrl(document.location.href)) and,
finding this test to be satisfied, returns early without triggering
the statechange event.  I have been unable to find any documentation
of jquery.history.js, so am unable to determine whether this is a bug
in jquery.history.js or expected behavior/a bug in exhibit.
Merge branch '2013-03-24_urls' of github.com:karger/exhibit
Merge pull request #7 from karger/2013-07-24_bugfix_hack_history

Hack to fix history mechanism in ie9