(was testing `srcdoc` and forgot to remove this before pushing)

Fix ghost adder

The adder is not off screen, it's in the top-left corner.

Hide the `<hypothesis-adder-toolbar>` element, rather than its
containing `<hypothesis-adder>` element, when hiding/showing the adder.

Since 56f5243e hiding the parent
`<hypothesis-adder>` element doesn't work because, to protect them from
third-party CSS elsewhere in the DOM, its child elements no longer
inherit its CSS properties.

Fixes https://github.com/hypothesis/client/issues/414

Adder() contains a `var self = this` line and a line that assigns the
`element` that `createAdderDOM()` returns to `this.element`, but it
usually accesses `element` via the local variable element (and
occassionally as `this.element`).

Change this to be consistent: assign `self.element = createAdderDOM()`;
always access it as `self.element` not `this.element`; delete the local
variable `element`.

This just makes the code a little simpler and more self-consistent.

Ignore all config other than direct linked ID  from host page.

configuration on the host page other than the query and annotations.

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

Adding group leave, switch, and view activity metrics

Split extract annotation query into two separate functions

For a future refactoring of this config code I need to have one function
per config setting (the function returns the value of the config
setting).

extractAnnotationQuery() is actually a single function for two config
settings - it returns either {query: *} or {annotations: *} depending on
what's in the URL #fragment.

This doesn't fit into my planned refactoring, so split
extractAnnotationQuery() into two settings functions: one for
config.query and one for config.annotations.

Refactor extract annotation query

Only match the `#annotations:<ID>` regex against the URL if the
`#annotation:<q|query>:<QUERY>` regex, which takes precedence, doesn't
find a match.

This also makes it clearer that the URL-safe base64 IDs comment applies
to `annotFragmentMatch` only not to `queryFragmentMatch`.

I think this makes the code more readable.

This both clarifies the intent of the code (what exception, thrown by
what, it's intending to catch) and reduces the chances of a bug where it
actually catches a different exception thrown by something else that it
didn't intend to catch.

Rewrite these tests to make them more descriptive, and clarify what the
behaviour of `extractAnnotationQuery()` actually is:

- Replace `unroll()` with a simple dynamic test generation approach that
  allows each test to have its own different `describe()` and `it()`
  strings

- Change the top-level describe from `describe('annotation queries'` to
  `describe('annotation.util.extractAnnotationQuery'`

- There was a test for what happens when a `#annotations:<ID>` fragment
  contains non-alphanumeric characters which used the test URL
  `'http://localhost:3000#annotations:\"TRYINGTOGETIN\");EVILSCRIPT()'),`.
  This seems to suggest that the alphanumeric characters restriction is a
  code injection defense, but I don't think it is. Replaced this with just
  `not%20alphanumeric`.

Fix extract-annotation-query.js to just export a function, instead of
exporting an object containing just a single function.

Tests and other tweaks to shared/settings.js

Add a new set of unit tests that test more cases.

Rename options to config in annotator

There are two reasons for renaming the `options` object to `config`:

**First**, it's more consistent. The file that creates this object is
called `config.js`, and the function that creates the object is called
`configFrom()`, and yet the object ends up getting called `options` (but
you have to look in another file, `main.js`, to find this out).

`config` is also used elsewhere as the name for the main configuration
object, for example in Pyramid/h, in the client docs ("Configuring the
Client", "configuration settings") and public API
(`class="js-hypothesis-config"` scripts and `window.hypothesisConfig()`
functions), etc.

These "options" that the `src/annotator/` code reads from the host page
also end up getting renamed to `hostPageConfig` when they get passed
over in to the `src/sidebar/` code.

**Second**, it's more unique. There are a number of other objects in the
`src/annotator/` code that are called options, sometimes the main
options object and another local options object are even used in the
same function. There's no other objects called config.