Reset location.hash when user submits a BLAST request (close #34).

Once the BLAST results are available users shouldn't have to scroll down
themselves to see the result.  SS does this by setting location.hash to
'result' once the BLAST results have been fetched causing browser to jump
to the BLAST results.

Now, if users need to re-blast, they will have to go back to the search form,
edit parameters, and click BLAST.  There are three ways a user can go back to
the search form: scroll up, refresh page, hit back button.  `location.hash` is
retained in the first two approach.  And browsers don't react if one tries to
set `location.hash` to the same value that it holds.  So SS wouldn't jump to
results for the second time if the user scrolled up, or did a page refresh to
get back to the search form, after viewing the results.  Instead SS would stay
at the current scroll location.

As a workaround, SS now resets `location.hash` to '' when user clicks BLAST.
And sets it back to 'result', as usual, when BLAST results are available.
Effectively, SS should always _jump_ to results after a successful BLAST.

Signed-off-by: Anurag Priyam <anurag08priyam@gmail.com>
Print version number on `sequenceserver -v`.

Signed-off-by: Anurag Priyam <anurag08priyam@gmail.com>
Depend on Bundler 1.2.x.

Not specifying a version number will cause RubyGems to settle for _any_ release
of Bundler that it might find on the user's system.  But the locally installed,
older release of Bundler might not be API compatible with newer release that
SequenceServer actually depends on, and might cause SequenceServer to break on
the user's machine.

We need at least Bundler 1.0.13.  But since I refer to the code of latest
release, it is probably best to depend on same, lest I should introduce a
change that depends on the public API provided by the newest release.

We depend on Bundler 1.2.x assuming it follows Semantic Versioning [1], so the
public API won't change in a point release.

[1]: http://semver.org/

Signed-off-by: Anurag Priyam <anurag08priyam@gmail.com>
Depend on Sinatra 1.3.x.

I don't really know if SequenceServer breaks b/w Sinatra 1.2.0 and 1.3.2.
But since I refer to the source code of the latest Sinatra release during
development, it is probably best to depend on the same.

We depend on 1.3.x since Sinatra follows Semantic Versioning [1], so public API
won't change in a point release.

[1]: http://semver.org/

Signed-off-by: Anurag Priyam <anurag08priyam@gmail.com>
Tighten dependency.

* Depend on Sinatra 1.3.x.
* Depend on Bundler 1.2.x.

SequenceServer makes use of the latest release of its dependencies.  This is
primarily because I refer to the source code of the latest release, and might
inadvertently introduce a change that depends on the latest public API.

I think SequenceServer should always depend on the latest, stable release. It
makes things easier for everyone.  You have the latest enhancements: bugfixes,
performance improvements, fixes for security vulnerabilities, newer API that
has more to offer, etc.

Signed-off-by: Anurag Priyam <anurag08priyam@gmail.com>
Release 0.8.2.

* Tighten dependency.
* Print version number on `sequenceserver -v`.
* Reset location.hash when user submits a BLAST request (close #34).

Signed-off-by: Anurag Priyam <anurag08priyam@gmail.com>