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

Wrap "stage" contents in a block in Jenkinsfile

This fixes a warning from Jenkins that using `stage` without specifying
a block is deprecated.

In preparation for executing the client release process entirely on
Jenkins, make update-changelog.js automatically update CHANGELOG.md with
a list of changes since the most recent tag, instead of requiring a
developer to do this manually.

This will lose the advantages of having a changelog written by humans, but
we primarily use other channels nowadays to notify staff and users about
Hypothesis product changes.

 - Add scripts/generate-change-list.js which generates a nicely
   formatted list of changes since the last release.
 - Use functions from generate-change-list.js to auto-populate section
   for new release in CHANGELOG.md when running `yarn version`.

Update API route definitions used by tests

 - Update the API index definitions used by the tests for the `api` service
   to be in sync with the actual index returned by https://hypothes.is/api/.

 - Move the definitions into a separate file to make them easier to update in
   future and add instructions on how to update them.

 - Fix two errors in the tests; use of "PUT" instead of "PATCH" for
   updating an annotation and an incorrect parameter name in the API call
   to remove a group member.

Support serving the client over SSL in development

Use custom name for global `require` function

Following the conventions of the "h" project [1], the client's asset
server (localhost:3001) and demo page server (localhost:3000) will be
served over SSL if a certificate (".tlscert.pem") and private key
(".tlskey.pem") are found in the root of the repository.

This can be useful for testing the development client on pages served
over SSL without having to disable mixed content warnings in the
browser.

[1] https://h.readthedocs.io/en/latest/developing/ssl/

Browserify bundles that make their modules available for other bundles
to consume define a global `require` function. This is then imported by
other bundles and used to resolve module lookups.

This `require` name can clash with web pages that use eg. `RequireJS`.
Most of the time this isn't a problem because all of the page's own code
has run by the time Hypothesis loads. If however the page loads
additional scripts after Hypothesis has been loaded, they will end up
finding Hypothesis's `require` instead of their own.

This commit resolves the issue by renaming the global `require` function
to `hypothesisRequire` in two steps:

 - The `externalRequireName` Browserify option changes the _exported_
   name.
 - A custom transform stream post-processes the Browserify bundle code
   to change the _imported_ name, since Browserify doesn't have an
   option for this itself.

A small fix was needed to the `boot.js` script build to avoid stripping
lines _after_ the sourcemap URL comment, instead of just that comment.

Fixes #779

Fix leaving a group from the client

https://github.com/hypothesis/h/commit/46e4bbadc991d550ca9706b5237e35d68675a6cc
made a breaking change to the public API of the endpoint for removing
the current user from a group by renaming the "user" path parameter to
"userid".

Given that this change has been out for some time, I have opted to fix
the client rather than revert the change in the service.

Fixes #774

Update core-js

Add aria label to share button in client menu

In addition to adding the label, this changes the <a> to a <button> as well.
Fixes https://github.com/hypothesis/product-backlog/issues/780

Fetch config via postMessage RPC if `requestConfigFromFrame` is set

This causes the client to fetch settings from an ancestor frame on
startup if necessary.

Implement `fetchConfig` function which fetches config from the host page
/ embedding web app and merges it with config rendered into the sidebar
HTML page.

This function supports a new method of fetching config from the embedder
by performing a "requestSidebarConfig" RPC call to the origin set with
the "requestSidebarConfigFromFrameWithOrigin" setting. That setting must
itself by set in the page where the embed.js script is loaded.

Also extract the `assertPromiseIsRejected` helper into `promise-util.js`
for re-use and add a note about needing to return the result.

Read sidebar app config asynchronously on startup

Add client for making JSON-RPC calls over postMessage

In preparation for introducing an optional new postMessage-based method
for the sidebar app to fetch configuration from its embedder, make the
setting fetch flow async.

- Move the Angular app startup logic into a function which receives
  settings as an argument.
- Add a function to merge config rendered into the sidebar app HTML
  page with config fetched asynchronously from a host frame.

Add "requestConfigFromFrame" string setting

Without this field all the test cases still pass, but for the wrong
reason, since the origin field is checked before other event properties.

Replace "var" with "const" or "let" everywhere

Update our JS standard library polyfills to the latest stable release.

This setting will cause the sidebar app to fetch its configuration via
a postMessage request to frames with the given origin on startup.

The setting is not actually used yet. This is coming in future commits.

We need a way for the client to request configuration from an embedding
frame over `postMessage`.

JSON-RPC is a well-known, simple and convenient format for RPC messages.

There are several npm packages which claim to offer this functionality
but at the time of writing, none appeared to be sufficiently well
tested/supported/documented.

There is an existing partial postMessage JSON-RPC server implementation in
src/sidebar/cross-origin-rpc.js. The non-app specific parts of that will
be moved into this module in future.

To ensure consistency going forwards, enforce usage of const/let