The sidebar had two separate watchers checking for a change in the
current user ID and focused group, each of which independently called
`loadAnnotations`. Therefore if both changed at the same time,
annotations could be loaded twice. This happens when logging out if a
private group was selected prior to doing so, since the group switches
to "Public" at the same time as the userid becomes `null`.

This commit fixes the issue by consolidating the check for a change in
group ID and a change in user ID into a single watcher. If either or
both change, `loadAnnotations` will only be called once.

Refetching of annotations when the logged-in user ID changes was
previously triggered by a complete reload of the `<sidebar-content>`
component via a `$route.reload()` call. This happened in response to a
`USER_CHANGED` event except for the first time that the profile was
fetched.

When using OAuth this broke because the test for whether this was the
first profile fetch or not was based on a change from null => non null
CSRF token (see `isInitialLoad` initialization). When using OAuth
however, there is no CSRF token.

This commit reworks refetching of annotations to remove the route
reloading and instead trigger it in the same way that it is triggered
when frames connect or disconnect, by calling
`SidebarContentController#loadAnnotations` when the logged-in userid
changes.

Rewrite viewFilter service and fix incorrect handling of any-field query terms in client-side search

Use profile display name in account menu

Render display name in new annotations

Render the display name if set

Populate the `user_info` field for new annotations from the logged-in
user's profile. This enables new annotation cards to render the user's
display name instead of their username if they have set one.

This logic is currently in the annotation component init function for
consistency with how the `user` field is initialized. However, it really
ought to be in the code that handles the `addAnnotations` Redux action.

If the user has set a display name, render that in the account menu
instead of their username.

If the display name is provided by the server in the annotation's
`user_info` field, render it instead of the username in annotation card
headers.

Fix OAuth popup being blocked by pop-up blocker in Firefox and IE

Use vendor-prefixed `msCrypto` property for IE 11

Remove unused refresh timer variable in OAuth service

Together with [1] this fixes the OAuth popup failing to appear when
clicking "Log in" in IE 11.

[1] https://github.com/hypothesis/client/pull/537

Make annotation of iframes opt-in

When the user clicked the "Log in" link, the URL of the
"oauth.authorize" endpoint was fetched via an async Promise-returning
method before the `window.open` call was made. This meant that the
`window.open` call did not happen in the turn of the event loop that was
triggered by the user action and so Firefox & IE's popup blockers deemed
the call to have happened outside the context of a user gesture and
prevented the window being opened.

Chrome, Safari & Edge have different heuristics and did not block the
popup before.

Fix the issue by opening the window directly when the user clicks on the
"Log in" button, at a dummy URL ("about:blank"), and then changing the
window's location once the authorization endpoint URL has been fetched.

Fixes #534

This was missed during 28bdb52f

The client's iframe support is not yet robust enough (see
https://github.com/hypothesis/client/issues/530) to enable it
automatically for all iframes on arbitrary web pages.

To support the needs of EPUB viewers and others in the meantime while
preventing problems on eg. pages with larger numbers of iframed ads,
require the publisher to opt iframes into annotation by adding the
"enable-annotation" attribute to them.

Run `prettier` on `frame-util.js` to fix up some minor formatting
inconsistencies.

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