Add Symbol polyfill

(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

This is needed for various ES6 language constructs, such as `for ... of`
loops, to work because the transpiled code depends on references to
properties of the `Symbol` object (eg. Symbol.iterator).

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