Add a new `annotator.config.settingsFrom#hostPageSetting(settingName)`
method that encapsulates a bunch of logic in one method:

- It always returns null if the client is from a browser extension.
  Browser extensions don't read settings from the host page.
- If the host page's `window.hypothesisConfig()` function returned a
  value for the requested setting, `hostPageSetting(settingName)` returns
  that value.
- If `hypothesisConfig()` doesn't return the setting it looks for it in
  `js-hypothesis-config` scripts in the host page
- If the setting isn't defined in either place it returns `undefined`.

(config 3/n): Turn the settings obj into a settingsFrom function 

annotator.config.settings currently exports an object containing
individual standalone functions for returning different settings'
values:

    module.exports = {
      app: appFunction,
      annotations: annotationsFunction,
      ...
    };

Change it to export just a single constructor function - settingsFrom()
- that returns an object containing the previously-exported functions as
methods:

    function settingsFrom(window_) {
      ...
      return {
        get app() { return app(); },
        get annotations() { return annotations(); },
        ...
      };
    }

    module.exports = settingsFrom;

Note that ES5 getters are used so that, even though app() and
annotations() are methods rather than simple properties now, they can
still be accessed as properties - settings.app not settings.app(). This
makes the code that uses this object slightly simpler, and makes mocking
this object in unit tests simpler.

The diff of this commit looks big, because the indentation of a lot of
code is changed, but it really is just changing functions into methods
and not actually changing the code of any of those functions.

The reason for turning functions into an object with methods is so that
the object that settingsFrom() returns can have state (by having closure
variables inside the settingsFrom() function). We don't make any use of
this state yet but future commits will do.

(config 2/n): Move configFuncSettingsFrom() into its own file

Cut-paste the configFuncSettingsFrom() function and its unit tests out
of settings.js and into its own config-func-settings-from.js file.

This is because in a future refactoring index.js isn't going to call
configFuncSettingsFrom() anymore, only settings.js will call it, which
would make configFuncSettingsFrom() a private helper function of
settings.js, but I don't want to lose configFuncSettingsFrom()'s unit
tests so I'm moving it into its own file from where settings.js (in the
future, index.js currently) can import and use it. This way
configFuncSettingsFrom() remains part of the public API of its
containing module and can have unit tests.

(config 1/n): Move isBrowserExtension() into own file

Upgrade gulp-sass

Convert tags service to JS

This fixes a build error with Node v8.

Multiple frame detection and injection

Enable ES2015 transpilation in the client

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

Tweak `isBrowserExtension()` to take just the `config.app` string that
it needs and not the entire `config` object as argument. This is
necessary for `isBrowserExtension()` to be called by `settings.js`
instead of `index.js` (as I want it to be in the future) - when it's
called by `settings.js` the `config` object as a whole won't be
available (and hasn't been constructed yet).

Cut-paste the `isBrowserExtension()` function and its unit tests out of
`settings.js` and into its own `is-browser-extension.js` file.

This is because in a future refactoring `index.js` isn't going to call
`isBrowserExtension()` anymore, only `settings.js` will call it, which
would make `isBrowserExtension()` a private helper function of
`settings.js`, but I don't want to lose `isBrowserExtension()`'s unit
tests so I'm moving it into its own file from where `settings.js` (in
the future, `index.js` currently) can import and use it. This way
`isBrowserExtension()` remains part of the public API of its containing
module and can have unit tests.

Extract isBrowserExtension() into a separate settings function

If the host page contains a service setting then the client should de…

Don't throw if hypothesisConfig() isn't a function

Don't throw on invalid JSON

Simplify reading query and annotations

We need to be able to support the client to work with different annotation
services, other than just `https://hypothes.is/api`.
If the settings from the host doesn't specify a service, the client should
fall back to using the default apiUrl which would be `https://hypothes.is/api`.

https://github.com/hypothesis/product-backlog/issues/278

Running the code through Babelify before instrumenting it for code
coverage resulted in incorrect statement location metadata. See the
"statementMap" sections of the two files in
https://gist.github.com/robertknight/4ec0f2c3509af61c31ffd574fe16cb74

Since Isparta already supports ES6 internally, it can instrument the
original untranspiled source, the problem can be resolved by switching
the order of the transforms. See
https://github.com/karma-runner/karma-coverage/issues/157#issuecomment-302133802

dom-anchor-fragment's package.json specifies that the untranspiled
source should be used in the browser, together with Browserify
configuration.

This isn't compatible with the Babelify configuration that is used to
transpile the main client's code.

Resolve the issue by configuring the client explicitly to use the
pre-transpiled version of the source in the package.

The previous version of dom-seek included untranspiled source and
provided Browserify transform configuration for an older version of
Babelify, which is incompatible with the version being used to transform
the client's main source.

The latest dom-seek release ships pre-transpiled code which doesn't have
this problem.