Instead of creating a new mechanism for the client's deliverer to set
the sidebar app URL and asset root, re-use the existing documented
system for configuring the client.

 - Rename 'appHtmlUrl' to 'sidebarAppUrl' to be more obvious to new
   developers.
 - Make `settings.js` usable without a polyfill for Object.assign()
   so that it can be used in the very small boot script.

Add a comment explaining why the two entry points for the client both
use the same script.

Add a new bundle (build/boot.js) which serves as the main entry point
for the client. This entry point will be used in two places:

 1. When embedded in a host web page it will add the bundle for the
    annotation layer (injector.bundle.js) to the page plus supporting
    assets.

 2. When included as the sole asset in the sidebar's HTML page
    it will add the bundle for the sidebar app (app.bundle.js) to the
    page plus supporting assets.

Having both entry points be a single script means that when it is
referenced in app.html, the browser will already have it cached locally,
saving a roundtrip.

In this commit the script just adds all <script> and <link> tags for the
annotation layer or sidebar to the document. In future it can be made
smarter - eg. by preloading sidebar assets when loaded in the host page
and not loading polyfills in newer browsers.

Cache access token promise not access token

Cache the access token request promise, not just the access token
itself.

This commit fixes a problem that the client would send multiple concurrent
access token requests if tokenGetter() was called multiple times before
a response to any of the HTTP requests was received:

1. tokenGetter() is called, sends an HTTP request for the access token
   and returns a Promise for the access token from the request's response

2. Before the HTTP response is received tokenGetter() is called again,
   sends another HTTP request, returns another Promise.

As soon as one access token response is received then tokenGetter()
caches the access token and just returns it, doesn't send any more HTTP
requests, but each time tokenGetter() is called *before the first access
token response has been received* it sends another, concurrent access
token request. It does not "know" that it already has an access token
request in-flight.

The fix is to cache the first access token request Promise when the first
access token request is sent and then just keep returning that Promise, instead
of sending more requests:

Instead of caching the access token itself (`cachedToken`) we now cache
a Promise for the access token (`accessTokenPromise`) the first
time we send the access token request.

Each further time that `tokenGetter()` is called, if it already has a
`accessTokenPromise`, then it just returns the Promise and doesn't
send another HTTP request. It now "knows" that it already has an access
token request in-flight.

Don't reuse OAuth grant tokens

Add test for failed grant token request

Don't delete cached OAuth access token

Simplify the oauth-auth service by not caching the grant token in memory
- it is (now) only used once anyway.

Don't reuse the OAuth grant token if the access token has expired.

The grant token is only intended to be used once, and if the access
token has expired then the grant token will likely have expired as well anyway.

A later commit will add support for refreshing an expired access token
using its refresh token, instead.

Add examples in docs for sidebar trigger and annotation count display.

When using OAuth (the host page provides an embedded grant token) don't
call auth.clearCache() on session update. The authorized user never
changes when using OAuth with a grant token embedded in the page, and
the oauth-auth service's clearCache() is a no-op anyway, so there is no
point in calling clearCache() here.

This fixes an issue that, when the client is embedded on a partner site
using third-party auth:

1. The client reads grant token that the client embeds in their page
   from the page
2. The oauth-auth service sends a grant token request, receives back an
   access token which it caches
3. session.js calls oauth-auth's clearCache(), which deletes the access
   token
4. The next time the access token is needed the oauth-auth sends a
   second grant token request, with the same grant token, and gets a
   second access token

So two grant token requests are sent, when only one was needed, because
the cached access token is deleted unnecessarily.

The fix is to make clearCache() in oauth-auth a no-op for now. For now
it never makes sense for oauth-auth to clear its cached access token.
OAuth is currently only used when the client is embedded in partner
sites and the grant token is embedded in the page by the client. Since
the grant token never changes, there's never any reason to clear the
access token and request a new one using the same grant token again (you
would just be requesting a new access token for the same user account).

Set initial annotation counts to 0 because annotation counters are not…

Remove unused SESSION_CHANGED event

Set initial annotation counts to 0 because annotation counters are not updated if a page has no annotations.

Minify production build and fix prod build in non-ES6 browsers

Ensure that NODE_ENV is set to 'production' when building the client for
release and thereby ensure that the JS and CSS is minified.

We are not currently transpiling client code using Babel, so this
doesn't work with our minifier or older browsers.

This event was fired by the `session` service but not listen for by any
other module.

Use new profile update endpoint for dismissing sidebar tutorial

Explicitly update vinyl-fs's graceful-fs dependency to v3.0.11.

graceful-fs v3.0.8 had a dependency on an internal Node module which no
longer exists in Node v7.

See https://github.com/gulpjs/gulp/issues/1843

Make `store.profile` an object containing `read` in preperation for the
upcoming changes where we will use the update profile endpoint for
updating a user's preferences.

Adding client metric tracking for interactions with annotations

In preparation for adding a profile update endpoint, the name of the
route for fetching the profile was renamed to 'profile.read'.

See https://github.com/hypothesis/h/commit/a3d45a4a4abb5b7b6f899eade5186820340a545c

Verify userid after connecting to WebSocket

Listen for the 'whoyouare' reply to the 'whoami' request sent after the
WebSocket connects and log a warning if the userid does not match the
logged-in user for any reason.

Show annotation counts on page.