Fix refreshing access tokens when laptop suspends

This commit fixes an issue that refresh token requests were being sent
too late if a laptop was suspended, even if the laptop was resumed again
in time to do the refresh.

For example if a laptop was suspended for 10 mins, then the refresh
request would be sent 10 mins later than it should have been and the
access token and refresh token would have already expired before the
refresh request was attempted.

The bug was due to a misunderstanding about how `window.setTimeout()`
works:

If you, say, use `setTimeout` to call a function in 10 minutes time,
then wait 5 minutes, then put the laptop to sleep for an hour, then
wake it up, **it will wait another 5 minutes and then call the
function**.

That is, the time that the laptop spent asleep does not count towards
the timeout, it pauses the timer and then continues the timer again when
the laptop wakes. This will also happen if the browser or OS suspends
the tab or app.

I've verified this behaviour in Chrome and Firefox on Linux, and it also
agrees with [this StackOverflow
answer](http://stackoverflow.com/questions/6346849/what-happens-to-settimeout-when-the-computer-goes-to-sleep/6347336#6347336)
and [the HTML5 spec on
`setTimeout`](https://www.w3.org/TR/2010/WD-html5-20101019/timers.html#timers):
"wait until the Document associated with the method context has been
fully active for a further timeout milliseconds (not necessarily
consecutively)."

This means that if you want to definitely call a function at a given
time (say 55 mins in the future) you can't just use `setTimeout` to set
a single timer for 55 mins like our code was doing - if the laptop is
suspended during those 55 mins then the timer won't go off until 55 mins
+ however long the laptop was suspended for.

To fix this change the code to repeatedly poll, every few seconds,
whether the current time is later than the access token expiry time
minus 5 minutes. If it is, then try to refresh the access token.

I'm using repeated calls to `window.setTimeout()` to implement this,
rather than one call to `window.setInterval()`, because with
`setTimeout()` it's easier to do a couple of things that the previous
implementation was already doing:

1. Not make any more refresh token requests while one is still in flight
2. Stop making further refresh token requests when one fails

Clarify in tooltip what flag button does

Branding updates

* master:
  Rename DO_{LOGIN,SIGNUP} to {LOGIN,SIGNUP}_REQUESTED
  Allow third-party annotation services to customize sign-up link handling

Allow publishers to customize "Sign up" link handling

Use consistent past-tense naming for all events in `bridge-events`.

Allow third-party annotation services to define a callback which is
invoked to handle the "Sign up" link in the client, in a similar way to
how the "Login" link is handled in this case.

Improve error when flagging when logged out

Don't show duplicate toastr messages at once

Improve the error message that's shown to the user when trying to flag
an annotation while logged out.

Instead of showing a "404 Not Found. Either the resource you requested
doesn't exist, or you are not currently authorized to see it." error
from the server, show a friendlier "You must be logged in to report an
annotation" message.

This is done client-side by checking whether the user is logged in when
they click the flag button, and if not showing an error instead of
sending the flag request to the API. This is because the API doesn't
respond with a unique "You must be logged in to flag" error that the
client could depend on, it just returns a 404, which could be for a
number of reasons (e.g. the annotation no longer exists).

The flag button on an annotation has a tooltip that says simply "Flag"
(or "Annotation has been flagged" if it's already flagged) but there's
no indication to the user what flagging is or does (even when they click
the button, all that happens is the flag turns red).

"Flagging" can certainly be misinterpreted. I think some apps use it as
a way to keep track of "special" or "favorite" items (usually called
"starring" in most modern apps), or have a variety of different "flags"
that you can apply to an email or whatever it is (important, work,
personal, etc, this is usually called "tagging" or "labelling" in most
modern apps).

This commit changes the tooltips to clarify that what the button does is
report the annotation to the moderators. I've used the verb "report"
rather than "flag" as I think "Report this annotation to the moderators"
sounds better than "Flag this annotation to the moderators".  Either way
I think "to the moderators" is important to clarify that this button
sends a message to the moderators and isn't, for example, just flagging
for personal use like starring / tagging / labeling.

Use `this` or `self` to refer to the controller instance in annotations

I've attempted to make the comment explaining that all initialization
code except for assigning bound methods goes in `init()` more succinct.

Make `sidebar/components/annotation` consistent with other code by using
`this` or `self` to refer to the controller instance instead of `vm`.

 * Replace `vm` with `this` or `self` (in nested functions)

 * Remove ESLint exception at the top of the file

 * Remove unused `$q` import

Exclude vendor code from coverage metrics

Do not show highlight indicator for censored annotations

Do not display moderation banner unless moderation metadata is present

Initialize `target` field for new replies

Annotations must have a `target` field and those returned by the server
always do. For compatibility reasons the server allows clients to submit
new annotations which provide the data in the `url` field instead.

This field was omitted when creating new replies in the client and this
broke an assumption in the `quote()` function.

The logic for creating the reply and extracting the quote is in the
wrong place, but I've left it here for the moment to keep the diff
minimal.

Fix exception when rendering a thread if the thread item has no
annotation. This happens if the thread item was created for an
annotation whose prior existence was inferred by a reply but no longer
exists.

Exclude vendored third-party code, including Annotator.js, from code
coverage metrics.

For annotations that have been saved we decide whether it is a highlight
based on whether it has a) selectors and b) content (tags or text). For
a censored/hidden annotation a non-moderator cannot tell whether it has
content.

Assume that censored annotations have content and are therefore not
highlights.

Annotations which are hidden may still be returned to non-moderators
with the `hidden` flag set, if they have replies. In this case the
moderation banner should not be shown.

Render "censored text" for hidden annotations

Fix variance in annotation share dialog test coverage

Rewrite and simplify the permissions service

Display a column of horizontal stripes to give the impression of
censored text for hidden annotations if the annotation's content has
been removed by the service.

Implements mock at https://github.com/hypothesis/product-backlog/issues/231#issuecomment-295600762

Remove a broken unit test

Git push to hardcoded https URL and master branch

As noted in this comment:

https://github.com/hypothesis/client/pull/356#discussion_r111998459

this test doesn't actually test what it says it does, and fixing the
test would require some refactoring of the code under test. For now,
just delete the test.