Enable reading openLoginForm and openSidebar from the host page

Whitelist the openLoginForm and openSidebar settings as being readable
from the host page even when the client is in a browser extension.

When you first install the Chrome extension it opens the /welcome page
in a tab, and it injects the openLoginForm and openSidebar settings into
the /welcome page in order to get the sidebar and login form to
automatically open on that page.

A previous change to prevent the Chrome extension from reading settings
from the page broke this /welcome page behaviour.

Fix it again by whitelisting the two required settings.

Of course this means that any page on the internet, not just the
/welcome page, and control these two settings, which is not what we
want, but it will do for now.

Add an allowInBrowserExt boolean option to hostPageSetting() so that
some host page settings can be white-listed as readable from the host
page even when the client is in a browser extension.

(config 4/n): Introduce hostPageSetting() method

Fixing js error on :3000 page

Add Symbol polyfill

Use the new `settings.hostPageSetting()` method in `index.js`.

This means that `index.js` no longer uses `shared/settings.js`
(`jsonConfigsFrom()`) or `configFuncSettingsFrom()`. These are both
encapsulated in `hostPageSetting()`.

Previously `index.js` blindly assigned a lot of property names and
values fo the `config` object using a couple of `Object.assign()` calls:

    Object.assign(config, sharedSettings.jsonConfigsFrom(window_.document));
    Object.assign(config, configFuncSettingsFrom(window_));

These `Object.assign()`s are now gone, and instead it explicitly assigns
each property to the `config` object by name:

    var config = {
      app: settings.app,
      query: settings.query,
      ...
      openLoginForm: settings.hostPageSetting('openLoginForm'),
      openSidebar: settings.hostPageSetting('openSidebar'),
      ...
    };

(Some of these settings were already being assigned in this way, but the
ones that uses `hostPageSetting()` are new.)

This also means that `index.js` no longer uses `isBrowserExtension()`.
Previously `index.js` contained logic to return early, declining to read
various config settings from the host page using its `Object.assign()`s,
if the client was running in a browser extension. This logic is also now
encapsulated in the new `settings.hostPageSetting()` method and so is
removed from `index.js`.

Add code to the `settings.annotations()` method so that, instead of
reading the setting from the URL only, it reads the annotations setting
from the `js-hypothesis-config` scripts in the host page or, failing
that, tries to read it from the URL.

In `index.js`, after `settings.annotations()` is called, there are two
`Object.assign()` calls that overwrite values already in the `config`
objects with any returned from `js-hypothesis-config` scripts or the
`window.hypothesisConfig()` function in the host page. So a
`config.annotations` setting from `settings.annotations()` already gets
overwritten by a `annotations` setting in a `js-hypothesis-config`
script or `hypothesisConfig()` function.

This commit makes that overwriting explicit, encapsulates it in the
`annotations()` method, and unit tests it.

Note that the two `Object.assign()`s are still present in `index.js` so
the `config.annotations` setting returned by the `annotations()` method
still gets overwritten by them, but this now has no effect as the
`annotations()` method will already have set `config.annotations` to the
same value that it will be overwritten with.

In a future commit the `Object.assign()`s will be removed and there
won't be any overwriting.

Note that **this will change the behaviour of the code** once the
`Object.assign()`s have been removed: the `annotations()` method reads
the annotations setting from `js-hypothesis-config` scripts but does not
read it from `window.hypothesisConfig()` any longer. I don't believe
it's necessary to read `annotations` from `hypothesisConfig()`.

Add code to the `settings.query()` method so that, instead of reading
the setting from the URL only, it reads the query setting from the
`js-hypothesis-config` scripts in the host page or, failing that, tries
to read it from the URL.

In `index.js`, after `settings.query()` is called, there are two
`Object.assign()` calls that overwrite values already in the `config`
objects with any returned from `js-hypothesis-config` scripts or the
`window.hypothesisConfig()` function in the host page. So a
`config.query` setting from `settings.query()` already gets overwritten
by a `query` setting in a `js-hypothesis-config` script or
`hypothesisConfig()` function.

This commit makes that overwriting explicit, encapsulates it in the
`query()` method, and unit tests it.

Note that the two `Object.assign()`s are still present in `index.js` so
the `config.query` setting returned by the `query()` method still gets
overwritten by them, but this now has no effect as the `query()` method
will already have set `config.query` to the same value that it will be
overwritten with.

In a future commit the `Object.assign()`s will be removed and there
won't be any overwriting.

Note that **this will change the behaviour of the code** once the
`Object.assign()`s have been removed: the `query()` method reads the
query setting from `js-hypothesis-config` scripts but does not read it
from `window.hypothesisConfig()` any longer. I don't believe it's
necessary to read `query` from `hypothesisConfig()`.

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

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