Flagging or unflagging an annotation previously updated the status
flag indicating whether an annotation had been flagged by the current
user but did not update the flag count if the user was also a moderator.

This needs to be done to make the moderation banner's state update when
a user who is also a moderator flags an annotation.

Tests for actions should live in the test module associated with the
module that defines the actions.

Use correct case for `flagCount` key

This property is camelCased rather than snake_cased in the annotation
response from the service.

Enable first-party users to flag annotations

Update moderation API use

Enable first-party users to flag annotations if the `flag_action`
feature flag is enabled for them.

Move the flag count to a helper which is easier to test and re-use.

The `hidden` state has been moved from the `annotation.moderation` key
to a top-level property of the annotation.

The previous code was incorrect because depending on the failure, the
error might not be an `Error`. This needs to be fixed in the API client
but for the moment, sidestep the problem by just displaying a fixed
string.

Moderation state was originally going to be retrieved via a separate API
call from /api/search but is now returned as a `moderation` field in the
annotation response.

This commit removes the separate `moderation` state from the Redux
store.

In the `<moderation-banner>` and `<annotation>` components, read the
moderation state from the annotation object instead of fetching it from
the app state.

After an annotation has been hidden or unhidden by a moderator, the
moderation state needs to be updated locally to reflect the change.

The `hide` API has now been implemented on the server. The `unhide` API
has been agreed but not yet implemented.

Adding branding config docs

Change "when it is being save" to "when it is being viewed" to avoid
implying that it might only apply while changes are being saved to the
server.

Show the flagged status for annotations that user has flagged.

Make failed API calls reject with an Error

Previously failed API calls from the `store` module were rejected with a
{ status, statusText, data, headers } response object.

This had several problems:

 * This violated the convention that promises should be rejected with
   Error or Error-like objects, so callers could not rely on the result
   having a `message` property.

 * It was up to each of the callers to translate the result into
   a message suitable for display, which is likely to lead to
   inconsistency.

 * Testing the translation of different kinds of failures into
   messages was mixed up in the `<annotation>` component tests.

This commit moves the translation of $http responses to `Error` objects
into the API client (`store`) module and adds tests.

Work around `getComputedStyle` bug in Firefox

Fix inconsistent component exports

This could return `null` in Firefox when the sidebar iframe is hidden.

Currently the app only ever has one `<thread-list>` instance, so
we can simplify the logic that gets the scroll root to just query for a
hard-coded selector.

`<thread-list>` uses `getComputedStyle` to find the nearest scrollable
ancestor element which it needs to know in order to scroll specific
annotations into view and determine which annotations are visible.

In Firefox `getComputedStyle` may return `null` if the iframe is hidden
- which may be the case when this code is called in the sidebar.  This
is considered a bug upstream. Work around it in the meantime by adding a
specific class (`js-scrollable`) to the scrollable element and testing
for that as a fallback.

Fixes #341

This fixes a small inconsistency in that most component modules exported
the object defining the component directly, whereas others exported an
object with the component as a property. There is no good reason to do
the latter.

Use Sphinx environment variable cross-references

Remove unused vm.feature variable

As unfortunate as the one-letter name is we agreed to just call it h and
not the service, and this is how it's used elsewhere in the docs.

This generates warnings if cross-references (for example to environment
variables) are broken.

When mentioning an environment variable in Sphinx docs do this:

```
:envvar:`FOO`
```

This will:

1. Render the envvar mention as a `<code class="std-envvar">`
   (among other CSS classes), this is then styled specially by the
   Sphinx theme

2. Automatically hyperlink it to the env var's definition on the
   env vars page

3. Generate a warning if an envvar with that name isn't defined
   (if the -n arg tp sphinx-build is used)

This is for consistency with our variable names and, for example,
environment variable names which use `HOSTNAME` rather than `HOST_NAME`.