Developing docs tweaks

sudo isn't required on all systems (e.g. macos)

For example Node is a prerequisite because we just tell you that you're
going to need it before you can follow these instructions. Gulp is not a
prerequisite, it's a dependency, because the instructions tell you how
to install it.

This OS-specific dependency was inadvertently added to the shrinkwrap in
ed4afca0

Add eslint rule to raise a warning if any of the tests are using the …

Add a guide to developing the Hypothesis client

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.

Add tests for login control.

Add CORS headers to assets served by the client's dev server, otherwise
the client's icon font will fail to load in many browsers.

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.