The `H_SERVICE_URL` environment variable is only used for one thing: to
set the value of the `defaultSidebarAppUrl` variable (to
https://hypothes.is/app.html in production or localhost:5000/app.html in dev)
by appending `/app.html` to the end of the environment variable's value.

For consistency with the config setting and variables that it's used to
control, rename `H_SERVICE_URL` to `SIDEBAR_APP_URL` and require the
user to include the `/app.html` ending in the environment variable's
value.

Also rewrite the documentation for this environment variable to make it
clearer what it's used for.

**Note**: This change means that developers who're using the
`H_SERVICE_URL` environment variable in their development environments
will need to:

1. Rename `H_SERVICE_URL` it to `SIDEBAR_APP_URL` in their environment
2. Append `/app.html` to the end of the environment variable's value

For example:

    export SIDEBAR_APP_URL="http://localhost:5000/app.html"

The developer docs for this environment variable have been updated to reflect
this.

Remove assetRoot and sidebarAppUrl from annotator

Remove the assetRoot and sidebarAppUrl config settings, which are read
from js-hypothesis-config objects in the host page, from the
src/annotator code.

These settings aren't used in the src/annotator code, they're used in
the src/boot code only.

Convert shared Bridge class to JS

Fix warning about loading Angular twice in tests

Convert localStorage service to JS

Remove unused "host" service

This reverts commit 4521cb4d.

Add --force to yarn install command

Attempting to fix this error with the client build on Jenkins:

    Error during loading "/data/jenkins/workspace/client_master-*/node_modules/karma-phantomjs-launcher" plugin:
      Path must be a string. Received null

Update docs to mandatory apiUrl field in the service.

 * Improve JSDoc comments

 * Remove `initClass` method which is unnecessary since all fields are
   initialized in the constructor

I removed the unnecessary use of Angular DI from the tests.

Enable reading openLoginForm and openSidebar from the host page

The Angular.js bundle was evaluated a second time because a module that
required angular was proxyquire-d in session-test.js. When
`proxyquire(...)` loads a module, it does so with a fresh, empty module
cache [1] which is removed once the `proxyquire(...)` call returns.

As a result, every module that is transitively required by the
proxyquire'd module will be re-evaluated during the `proxyquire(...)`
call.

Aside from the performance cost for large modules, this is also bad for
any module which has side-effects as part of its evaluation. Angular
happens to detect this and abort when evaluated a second time.

The fix here is to use Angular's DI system to mock the only stubbed
dependencies instead of proxyquire.

[1] The _module cache_ is a (module ID/name => exports object) map.

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

These events are never emitted by other code.

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).