When a search API request returns results, the returned annotations are
added to the app state and this transition triggers a digest cycle.

When there are no results however, this was not happening and the value
of the 'isLoading()' function changed but no digest cycle was triggered
to pick this up and reflect it in the UI.

Since SearchClient's 'end' event is emitted asynchronously via a Promise
callback, $scope.$apply() or $evalAsync() must be used to ensure that
change detection runs.

The real solution will be to store all the information required to
determine the loading/not-loading state in the Redux store, so that any
transition automatically triggers a digest cycle. This requires some
more extensive refactoring however.

Add ESLint configuration and use it to replace JSCS / JSHint

These have been replaced by ESLint

For stylistic consistency, require semicolons rather than relying on
ASI.

Checking for return values in Array callbacks found several incorrect
uses of Array.map() where Array.forEach() should have been used.

This will aid migration to let/const in future

This will ease migration to let/const in future.

 - Remove unused variables. Note that ESLint is smarter than JSHint in
   that it realizes that vars which are assigned but never read are
   unused.

 - Add missing `angular` require statements.

 - Add ESLint suppressions where necessary

Add a basic ESLint configuration which uses ESLint' recommended
settings to check for basic errors such as undefined vars and unused
variables.

Improve tab bar input handling and accessibility

Use anchor rather than link elements for the tab bar items so that they
are focusable via keyboard navigation.

Also follow code conventions and use 'is-<state>' for element states set in JS.

Focus the Annotation and Notes tabs on touch or mouse down rather than
click.

This makes the tabs act more like tabs in native apps and feel more
responsive.

Since Angular does not provide a built-in attribute directive for
handling touch events, implement a custom one.

Make Annotation and Notes tab bar sticky

Make Annotation and Notes tab bar stick to top of the viewport when the
annotation list is scrolled down.

This relies on support for `position: sticky` which is available in
recent versions of Firefox and Safari*. On browsers where
`position: sticky` is not supported, the tab bar will just scroll
off-screen when scrolling the annotation list down.

Because annotation cards may now be displayed under the tabs, add a
background color, Z index and negative horizontal margin to the tabs
component so that any part of an annotation card under the tab bar is
not visible.

* In Chrome v52 this feature is available but only when the
  'Experimental web platform features' flag is on.

Selection tabs tweaks.

Fix PR comments including some UI tweaks and bug fixes.

Hide no annotations/notes message when annotations are still loading.
When the annotations are still loading, a 0 annotations message shows for a flash of a
second before the list loads. Avoid this by only displaying the 0 state after the
annotations have finished loading.

If selected annotation/note is deleted, default selected tab to annotation.
If a user lands on a direct link for a deleted annotation, the button to take the user
back to the list of annotations/notes should by default be for annotations.
On clearning the selection, filter annotations according to the selected tab type.

Fix broken standalone page for notes.
selectedTab was set to annotations by default, even for standalone pages.
selectedTab should be undefined for a standalone page because there are no tabs to select from.
select the annotations tab by default for the sidebar alone.

Change copy for empty annotaitons/notes state.

Add a set of `npm version` scripts which can be used to tag and publish
a new release of the client with:

  npm version major|minor|patch
  npm publish

Where most releases will use `npm version minor`.

Add a change log

Add a change log for the Hypothesis client, following the format
suggested at http://keepachangelog.com/

This was a workaround for an issue with proxyquire and PhantomJS 1.9.

It is no longer needed following the upgrade to PhantomJS 2.x

For now we only build the client and run the tests.

Remove the ban on using console.log() in tests

Simplify request preparation in `store.js`

This was intended to prevent console.{log,warn,...} calls accidentally
being left in test code.

However the result was very confusing for H developers who only
occassionally worked with the H client test suite.

This problem is better solved by a linter.

Upgrade PhantomJS from 1.x to 2.x

Fix new replies being moved to the newly focused group

Use "log in"/"log out"/"sign up" consistently

Unless there is a clear reason not to do so, it is generally preferred
to use methods from the ECMA standard lib.

Rather than using a $http request transform to preprocess the data,
just pass the data object into the `stripInternalProperties` function
directly.

Previously the `group` and `permissions` properties of new replies were
set _after_ creating the reply with `createAnnotation()`. This meant
that the new reply did not have the correct group and permissions when
it was filtered for the first time by the `buildThread()` function.

Work around a bug in Karma 1.10 [1] which caused console messages from
tests not to be propagated to the terminal.

A fix has been accepted upstream and this workaround can be removed
when the next release of Karma is made.

[1] See https://github.com/litixsoft/karma-mocha-reporter/issues/67