Always use OAuth if cookie storage is blocked

Work around Chrome bug causing sidebar to become invisible

Work around a Chrome bug [1] that can cause the sidebar to become
invisible if:

 1. The sidebar app is loaded from a Chrome extension AND
 2. The current tab was opened by clicking a link inside the sidebar
    app in a different tab.

When the issue occurs, the sidebar web app loads and runs normally but
is just not visible on screen. This happens due to an internal issue in
Chrome which can be avoided adding `rel="noopener"` to all "normal" [2]
links in the client that open URLs in a new tab/window.

Doing so enables Chrome to use a separate process for the Hypothesis
client in the new tab in step (2) than the one used for the Hypothesis
client in step (1). This change also prevents potential tab-jacking
attacks in all browsers that support `rel="noopener"`.

Fixes #516

[1] https://bugs.chromium.org/p/chromium/issues/detail?id=753314
[2] ie. Those which do not use JS to handle the link

Use the `group.member.delete` API route to leave a group

Replace use of the undocumented and cookie-authenticated
`POST /groups/:id/leave` endpoint for leaving a group with the API
token-authenticated and documented (in the API route directory) method
for leaving a group.

This enables leaving a group to work when cookie authentication is
unavailable.

If third party cookies are blocked then OAuth is the only option for
authentication. Third party cookies may be blocked either by
privacy-enhancing extensions or browser settings, for example:

In Safari:
 1. Go to Settings -> Privacy
 2. Set "Cookies and website data" to "Allow from current website only"

In Chrome:
 1. Go to chrome://settings/content/cookies
 2. Enable "Block third-party cookies"
 3. Check that the h service domain is not listed under "Allow", which
    is something that the Hypothesis extensions do automatically.

Once OAuth has been shipped for all users, this code can be deleted.

Get OAuth authorization endpoints from `/api/links`

Use the "apiRoutes" service to get the URLs of the `/oauth/authorize`
and `/oauth/revoke` endpoints from `/api/links` instead of from
"oauthAuthorizeUrl" and "oauthRevokeUrl" in app settings.

This makes the client's behavior more consistent in terms of getting all
links to pages within the service from the `/api/links` route.

It also paves the way to enabling the client to use multiple annotation
services, each of which is defined by a single entrypoint (the `/api`
route) from which all other API routes and links into the service are
obtained.

Make these services use the "apiRoutes" service introduced in the
previous commit to fetch the API route directory and page links.

Fetching the API route directory is currently the responsibility of the
API client ("store") service. The "store" service makes authenticated
API calls and therefore depends on the "auth" service.

This means that we cannot use the API route directory or the page links
returned from `/api/links` in the auth service itself, as this would
introduce a circular dependency.

Factoring out the responsibility for fetching the `/api` and
`/api/links` endpoints into a separate service which does not use
authentication provides a way to resolve this problem.

It also makes testing some aspects of handling these endpoints, such as
caching and auto-retry if the HTTP request fails, a little easier.

Deprecate openLoginForm setting and make a no-op when using OAuth

Reload tokens and profile when stored tokens are changed by another client instance

Remove logic to refresh access token before it expires.

When using OAuth clicking "Log In" triggers a pop-up window which
requires user interaction in most browsers. Therefore the
"openLoginForm" option cannot be respected when using OAuth and would be
annoying anyway.

Fixes #515

Auth codes can only be used once, so clear the code just before
performing token exchange to ensure that it is not reused later.

With this change, logins are automatically synced across different tabs
in the same browser session.

Listen for "storage" events that are emitted when another client
refreshes access/refresh tokens and reload them when that occurs.

Refresh tokens now have a much longer lifetime [1] than access tokens,
therefore it is no longer necessary to refresh them before the access
token expires.

Instead the token is refreshed on-demand when an API request is made if
the access token has expired at that point.

[1] https://github.com/hypothesis/h/pull/4623

Implement logout when using OAuth

Use the service's OAuth token revocation endpoint [1] to revoke access
and refresh tokens when the user logs out.

[1] https://github.com/hypothesis/h/pull/4620

When using cookie-based auth, login / logout happens via HTTP requests
made by the "session" service and the auth service has to be explicitly
notified afterwards via `auth.clearCache()`.

When using OAuth-based auth on the other hand, login / logout happens
through the auth service itself, so there is no need to ask the auth
service to clear cached credentials afterwards.

Implement logging out in the OAuth authorization service when using a
first-party account.

This currently just causes any credentials cached in memory or local
storage to be forgotten and the user's profile to be reloaded. Once a
token revocation endpoint is available, the "Log out" button could also
trigger that as well.

Use correct request params when exchanging auth code for tokens

HTML5 Audio elements

Made changes suggested in code review:
https://github.com/hypothesis/client/pull/508#pullrequestreview-53812970
.

Tiny fix to the test to account for URLs that may have had uppercase
letters (the audio embed converts to lowercase to account for links to
.MP3 files rather than .mp3)