Adjust spinner positioning and convert to component

Set a useful title on the sidebar iframe

This went unnoticed because it turns out that `yarn version` does not
actually run the postversion hook if `--no-git-tag-version` is
specified. See https://github.com/yarnpkg/yarn/issues/5358

Deploy QA release of client as part of master branch builds

This makes it easier to identify the purpose of the frame when
navigating the page with assistive technology.

Fixes https://github.com/hypothesis/product-backlog/issues/784

 - Remove a semantically incorrect `<button>` wrapping the loading
   spinner and a redundant wrapping `<span>`.
 - Vertically center the spinner by adding a wrapper `<div>` in the
   spinner component itself, so that there is less of a visual shift
   when switching between displaying the loading indicator and the
   search bar.
 - Add a meaningful title attribute to the spinner. Properly indicating
   when the sidebar's content is changing/being loaded to ATs requires
   additional work which is not tackled here.

This is the last remaining directive which should be a component.

The short-lived max-age value set previously was overridden by the
higher value of 1800 (30 mins) set in CloudFlare's "Browser Cache TTL"
setting under Page Rules for cdn.hypothes.is.

Resolve this by simply disabling caching of the entry point for qa
deployments. This means that https://cdn.hypothes.is/hypothesis@qa will
always return the boot script for the latest client QA release.

Add a new build stage to Jenkins CI builds of the master branch which
deploys a "QA" build to S3. This QA build:

 - Has a pre-release version number of the form `X.Y.Z-{commit hash}`
 - Has a stable URL at https://cdn.hypothes.is/hypothesis@qa
   (as opposed to https://cdn.hypothes.is/hypothesis for the prod build)
 - Loads the sidebar app from qa-h (https://qa.hypothes.is/app.html)
 - Does not update the changelog or create a Git tag or GitHub release

This build is currently not deployed to npm at all, but we might need to
do that in future if we were to create a QA deployment of the browser
extension with it.

---

 - Add a QA deploy step to the Jenkins build.
 - Skip GitHub release creation and changelog updates for pre-release
   versions used for QA deployments.
 - Remove the preversion.sh script, which is no longer needed since the
   builds always run in Jenkins and not on a developer's system.
 - Support specifying the npm tag to check in `wait-for-npm-release.sh`,
   though this is not used in the final version of this commit.

Replace the generic Docker-based s3-npm-publish tool with a JS script in the
client repo which is tailored more specifically to the needs of client
deployments:

 - Avoid creating the `hypothesis@X.Y` and `hypothesis@X` aliases which we
   never used.

 - Support uploading a copy of the entry point under a version-indepenent
   alias, regardless of whether this is a pre-release or not.

   This will enable creating a stable URL which points to the current QA
   version of the client.

 - Deploy the package directly from the current working directory. This saves
   the need to wait for publication to npm to complete, or the need to
   actually publish the package to npm at all in the case of the QA
   release.

Add service.groups setting to filter groups

This option is being added initially to support the LMS application
where it is important that students annotate in the correct group for
the course that the active assignment belongs to.

Wait for npm release to complete before deploying to CDN

Use build milestones to automatically abort old builds

npm packages are not immediately available after "npm publish" returns.
Wait until the package has been released before attempting to deploy it
to the CDN. This should fix the failure seen in
https://jenkins.hypothes.is/job/client/job/master/745/console.

Use milestones to automatically abort older builds when a newer build
reaches the same step of the pipeline.

This mirrors the use of milestones in h's Jenkins pipeline.

Add missing polyfill for IE 11 compatibility when annotating PDFs

This package was already depended upon indirectly but following the
previous commit is now a direct dependency of the client.

The `seek` function from the `dom-seek` package expects its
`NodeIterator` argument to have a `referenceNode` property, which is
missing in IE 11.

Use the dom-node-iterator package recommended by the dom-seek README [1] to
polyfill optional-ness of arguments to `document.createNodeIterator` and
the missing properties on the returned `NodeIterator` object.

dom-node-iterator provides several ways to use the polyfill. This commit
uses the method that prefers the browser's native implementation if possible
and does not pollute the global scope, which could affect JS code
outside of the Hypothesis client.

There is one other place where we use `createNodeIterator` but in that
context the missing properties are not used so the polyfill is not
needed.

Fixes #762

[1] https://github.com/tilgovi/dom-seek/blob/master/README.md

Fix "Log in" links in sidebar content area not opening login prompt.

The loggedout-message controller should bind onLogin. The sidebar-content
controller should also bind onLogin and call vm.login(). Prevously this behavior
was broken.

Fix IE 11 JS error which annotating PDFs.

Skip builds of automated commits on Jenkins

The `whatToShow`, `filter` and `expandEntityReferences` arguments for
`Document.createNodeIterator()` are mandatory in IE although optional
according to the spec.
Pass default values to fix JS console errors.

See: https://github.com/hypothesis/client/issues/762

As part of the deployment process Jenkins creates a new commit on master
in order to bump the npm package version.

There is no point in creating an automated build of these commits, which
can be identified by the commiter name.

Move remaining client release steps to Jenkins

When performing a Jenkins CI build of the "master" branch, prompt the
user to deploy and then after they approve, execute the same release
process that a developer currently executes on their machine, namely:

 1. Update the changelog
 2. Run "yarn version" to update the package version, create a tag and GitHub release.

After these steps the release process continues on Jenkins as before,
with an npm package published and the build deployed to an S3-backed CDN
using the s3-npm-publish tool.

Enabling publishing the release entirely from Jenkins required some
additional changes:

 - Use a Debian Stretch-based Node container, to get a newer Git
   version which supports "taggerdate", used by the changelog scripts.
 - Disable Git tag signing, since this is not set up on Jenkins.
 - Do not run "make test" from the preversion script, since this has
   already been run by Jenkins earlier in the process.

Additionally to facilitate testing of this branch I added support for
specifying a prerelease version suffix. This made it possible to test
the whole deployment process without updating the live version of the
client. In future this will likely come in useful for doing staging/QA
releases.

Modify `update-changelog.js` to generate the list of changes itself