Add an initial guide to developing the Hypothesis client, covering:

 - Installation
 - Getting a local build of the client working with the browser
   extension or a local Hypothesis service
 - Running tests
 - Some basic pointers on code style and where to find guidance for
   creating pull requests

This guide assumes that the service is configured to use the client's
new boot script.

Due to a problem where an earlier version of 1.0.0 and 1.1.0 were
published to npm and then unpublished, thereby preventing re-use of
these versions, we're going to skip straight to 1.2.0.

Call partner provided login callback

An inconsistency crept in where the annotator code reads settings from
JSON script tags with a 'js-hypothesis-config' class name but the sidebar app
reads settings from JSON script tags with a 'js-hypothesis-settings'
class name. The boot script ended up using 'js-hypothesis-settings'
which is the default class name specified in `settings.js`.

We should use the same name everywhere, which needs to be
'js-hypothesis-config' since that is used by the public documentation
[1].

This commit changes the default class to `js-hypothesis-config` and
removes the ability to specify alternative class names when calling
`settings()`.

The extension and service will need to be updated to use the new class
name.

[1] See docs/config.md

Add an express server which serves the package's contents.

Fix PDF quote anchoring (Part II)

When the client is embedded in a partner site and a login button in the
client is clicked, call the JavaScript onLogin function that was
provided to us by the partner via the window.hypothesisConfig function.

When not embedded in a partner site, just prompt for a first-party login
as normal.

Note that this means that if the client is embedded in a partner site
with no onLogin callback in window.hypothesisConfig, then nothing will
happen when the login button in the client is clicked.

Separate bridge events sent from sidebar to annotator and from annotator
to sidebar into two separate sections in the source code. Just to make
documentation of the events clearer.

 - /hypothesis and /hypothesis@X.Y.Z serve the boot script

 - /hypothesis/X.Y.Z/ serves the files for a given version of the
   package

The change from defining a `window.hypothesisConfig` function to using a
script config tag was left over from an earlier version of the package
content server work.

This is now just getting distracting amidst the more important
information that gets logged during a build.

Print the sidebar app URL and asset root URL that were baked into the
client after the first build.

This is useful to verify that the build was run with the expected
environment.

To facilitate testing the client on devices that are not the same as the
one the package server and Hypothesis dev server are running on, it is
useful to be able to set the hostname for URLs that point to the package
content server that `gulp watch` runs.

This commit adds support for setting this via a `PACKAGE_SERVER_HOSTNAME`
env var.

When building the client in development mode, make the client load
assets from the package content server by default.

Also if `H_SERVICE_URL` is set, bake that service's /app.html endpoint
into the boot script.

The live reload server's example page was modified to use a script tag
for config settings because the boot script currently only reads that
config source and does not use `window.hypothesisConfig()`.

In order to use the sidebar app from the local service, the service
needs to be configured to serve the local client by setting the
'CLIENT_URL' env var before running the devserver and in the client, the
'H_SERVICE_URL' env var needs to be pointed at the devserver host.

Make the package content server mirror unpkg's behavior in that:

 - The entry point for a package is located at `/{packageName}@{version}`

 - Requests without a package version specified redirect to the
   corresponding path for the latest package version

Add an express server which serve's the package's contents in a manner
similar to unpkg:

 - The '/' route serves the package's entry point script

 - Other routes serve files from the package

This can be used together with the CLIENT_URL setting in the Hypothesis
service to configure the service to serve the local development version
of the client instead of the production version.

Looking at the `anchor` function, it is clearly intended that the
position selector is optional for anchoring, as is the case for HTML
anchoring. However, anchoring using only a quote selector did not
actually work. This was in part due to the bug fixed in the previous
commit but also because of a missing check for a null position selector
when populating the (quote,position) cache.

In order for the test to pass using only a quote, it was necessary to
change the search string to a unique quote which only occurs once in the
document. Otherwise the quote anchoring found the occurrence of
'Netherfield Park' on the non-rendered page 1.

The `findInPages` function was supposed to search for a quote looking
at each of the page indexes in the input array, in order.

However because of the way that `next` was used, this function ended up
only searching the first page in the list. The `then(attempt, next)`
code was intended to try the current page and then move to the next in
the list if no match was found. However the `next` function is not
called if `attempt` throws in this context.

The `pdfContent` var in the test was renamed to `pdfPages` for clarity.

Fix PDF quote anchoring

See https://github.com/hypothesis/client/pull/261#discussion_r103251150

The previous syntax ended up executing:

  docker run -d hypothesis s3://cdn.hypothes.is nickstenning/s3-npm-publish

So `hypothesis` was interpreted as the Docker image name instead of an
argument. Passing the args as the second ('command') argument to
`Image.withRun` results in the correct command being executed:

  docker run -d nickstenning/s3-npm-publish hypothesis s3://cdn.hypothes.is

Upload the client to the S3 bucket behind cdn.hypothes.is after
publishing to npm. The service will then redirect requests for /embed.js
to cdn.hypothes.is/hypothesis

We decided to publish the client's assets to a Hypothesis-specific
domain because publishers (eg. https://internethealthreport.org) may
want to use CSP to restrict where assets are loaded from and they won't
want to whitelist the whole of npm.

This also gives us better control over caching headers used on assets.

Improves performance and includes a number of bug fixes. See
https://github.com/showdownjs/showdown/blob/master/CHANGELOG.md for
changes.

Several tests required small changes because the rendering of
`para1\n\npara2` changed from:

  `<p>para1</p>\n\n<p>para2</p>`

To the visually equivalent:

  `<p>para1</p>\n<p>para2</p>`

This test fails without the `toPositionAnchor` fix in the previous
commit.

This method used to exist in the `dom-anchor-text-quote` library but got
lost when the class was moved to a wrapper in `types.coffee` after the
upgrade to dom-anchor-text-quote v3.x.

This method is used by PDF anchoring and its absence caused quote
anchoring to throw an exception. The majority of PDF annotations still
continued to anchor because the position anchor still worked.

This commit also adds some basic documentation to the `types` module and
some basic API tests.

Make this file easier to understand for the next person who tries to
read it.

The release notes were missing on the GitHub Releases page for the
client for several recent releases. This happened because of incorrect
heading levels used for subsections within a release in the CHANGELOG
file.

Don't treat annotation quotes (TextQuoteSelector.exact) as HTML