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.

 * Enable Babelify transform for Browserify in tests.

 * Rename `await` helper function because `await` is a reserved keyword
   in ES2015+.

Enable use of ES6 language features via Babel in the sidebar app and
annotator code.

 - Update Babelify to the current version
 - Add preset for transpiling ES2015

Log a warning, rather than throwing an error, if
window.hypothesisConfig() exists but isn't a function.

"Warn but continue" is in line with our general approach to handling
invalid configuration in the client. For example if there's an invalid
js-hypothesis-config script in the page it logs a warning and continues.

For some required config settings, such as config.app, if the setting is
invalid then the client crashes out immediately because it can't
continue. But otherwise it should warn and continue.

Don't throw an error when parsing an invalid js-hypothesis-config JSON
script.

This error thrown by shared.settings#jsonConfigsFrom() was caught in one
of the places where that function is called, but not in other places
where it's called.

Move the error catching and warning logging into the shared function
instead.

This now means, for example, that boot/index.js no longer crashes
(bringing down the entire app) if the host page contains an invalid
js-hypothesis-config.

Unfortunately since jsonConfigsFrom() is called _twice_ on page load to
read the same js-hypothesis-config objects from the host page (it's
called once by boot/index.js and once by annotator/config/config.js) if
there's an invalid js-hypothesis-config a warning about it will be
logged twice.