Previously the communication between the sidebar and host frame was
implemented by a shared AnnotationSync class, with a 'crossframe'
service which abstracted the event bus on each side.

This design however assumed that both sides wanted to listen to
the same messages and react to them in similar ways. This is not
the case, especially given the change to use Redux for state
management in the sidebar app.

This commit replaces the crossframe service and AnnotationSync class
with a new 'frameSync' service which implements only the event
listeners and sidebar -> page RPC calls that are actually needed.

As a result, local annotation tags for annotations loaded via the API
can now be assigned by the reducer in the Redux store, making this
easier to test and getting us another step closer to making Annotation
objects immutable in the sidebar app.

When calculating the count of pending updates that is used to determine
whether to show the 'Apply Updates' icon or not, count deletions.

In addition to changing the count calculation itself, this also requires
that pending deletions are discarded for annotations that are not
currently loaded. Such notifications may be received because the
deletion may have happened in an un-focused group. Unlike create/update
notifications, no group information is included in the notification
itself so we look up the ID in the local store.

Update icon for applying updates to the current page

As per discussion at
https://hypothes-is.slack.com/archives/frontend/p1474276933000039,
adjust the wording of the 'Apply Update' icon tooltip to avoid "update"
being misinterpreted as referring to a software update.

Update icon to match current design from https://trello.com/c/tRZ2H7iH
and remove the update count, as per the most recent comments on the
Trello card.

The deferred update UI was added primarily to avoid the problem of
annotation updates being distracting while a user is composing
annotations in the sidebar. This is less relevant on the stream.

Additionally fix a bug where updates from unfocused groups were not
shown on the stream, since the stream shows updates from all groups.

Since we discard all pending updates and deletions when switching
groups, discard create/update notifications about annotations in
unfocused groups as soon as we receive them.

This fixes the issue where the 'Apply Update' badge counted updates
from other groups, with the result that clicking the badge did not
show any changes.

Move the logic that updates the focused group for new annotations
out of the <annotation> component and into a service.

This fixes the issue where the event handler does not get invoked if no
<annotation> component instance exists for an annotation because it is
currently scrolled off-screen.

Fixes #105

Previously when switching groups all of the currently loaded annotations
would be unloaded and then potentially outdated copies of the annotation
from the drafts store would be reloaded into the annotation store.

This commit fixes that problem by:

 1. Only unloading saved annotations when switching groups.

 2. Only storing the annotation ID and tag in the drafts service, to
    ensure that we don't try to use it as a complete annotation anywhere

A consequence of (1) is that new, unsaved annotations no-longer briefly
disappear when switching groups.

This fixes the problem described in #109 where the orphan status of a
new annotation is lost when switching groups. It does not fix the
problem where the new annotation immediately becomes an orphan.

The logic to remove new and empty annotations used to live in the
<annotation> component because that was the only part of the code that
had access to the state of unsaved changes.

Since <annotation> instances are only created for on-screen annotations,
this can result in empty drafts not being removed if the empty
annotation is off-screen.

Now that the canonical content of unsaved annotations is stored in the
drafts service, we can move the logic outside of the annotation
component and fix this problem.

Fixes #97

Defer realtime update

When the focused group changes, pending updates to already loaded
annotations and deletions of already loaded annotations will be cleared
in the ANNOTATIONS_UNLOADED event handler. Updates/deletions for
annotations not yet loaded were not cleared however.

See https://github.com/hypothesis/client/pull/106#pullrequestreview-139177

Use the <svg-icon> component to render a refresh icon in the top bar and
adjust the styling to center the icon and pending update count
vertically.

Following the approach we have implemented for using <svg> icons on the
website without all of the hassle that comes with icon fonts, implement
an <svg-icon> component which renders icons as inline SVGs in the
client and add the 'refresh' icon for use in the top bar.

Prevent the apply updates button from being squashed horizontally and
thus wrapping onto multiple lines

Implement support for tooltips that point up at the target element and
use this facility for the 'Apply Updates' icon in the toolbar.

To avoid having the contents of the sidebar shift in a distracting way
while the user is reading or editing an annotation, do not apply
real-time updates received via the WS immediately but instead alert the
user to the updates via an icon in the top-bar and apply the updates
when the user clicks the button.

This commit implements support for caching updates in the streamer,
showing an icon and applying updates when the user clicks the icon.

Known issues:

 - The icon does not currently match the Refresh icon in the specs

 - The tooltip sits above the icon pointing down, instead of pointing
   up as per the mocks

Refactor Redux store into smaller modules

Use helper functions to take the set of action creator and selector
functions exported by each module and expose them on annotationUI.

Split the large switch statements in each reducer function
into objects which map action types to state update functions.

These functions are then composed together with a `createReducer`
helper defined in `reducers/util`

For the benefit of developers who are not familiar with Redux and
Elm-style architectures, add documentation at the top of the
annotationUI module which explains how state is managed in the app.

The `annotationUI` module evolved from before we used Redux to manage
app state and it was getting large and doing too much. This PR splits
out most of the logic into smaller modules in the `reducers` folder. The
`annotationUI` module continues to present the same exports as before to
avoid needing to change too much in one commit. Each module in `reducers/`
defines:

 - An `init` function which returns the initial state relating to some
   aspect of the application
 - A set of action types, relating to that aspect of the application
 - An `update` function which processes those actions
 - A set of action creators, which are helper functions that create
   these actions
 - A set of selector functions, which are helper functions that return
   derived data from this state

There is a root module in reducers/index.js which combines the actions,
init function and update functions from each module into a single init
and update function which can be used to initialize the Redux store.

Action creators which require access to the current app state or are
asynchronous, such as `addAnnotations` return thunks. See
https://github.com/gaearon/redux-thunk#motivation . Several
selection-related action creators currently return thunks but can be
refactored in future into plain actions.

To avoid making this commit too large, annotationUI continues to export
wrappers around the action creators so that code outside the Redux store
and tests do not need to be changed.

Add temporary timestamps to new annotations (for sorting)

Brand new annotations (and page notes) are currently displayed as editor
widgets in the sidebar alongside all the existing annotation cards. This
means they need to be sortable.

Sorting by location isn't a problem, because the annotation already
carries the document location information by the time it gets to
`addAnnotations`, but sorting by the updated date is, because currently
the `created` and `updated` fields are only provided when the server
sends back the saved annotation.

This commit changes that by adding temporary `created` and `updated`
timestamps to new annotations (those without an ID). These will be
ignored entirely by the server, and overwritten when the annotation is
saved.

If for whatever reason `addAnnotations` is called with a new annotation
that already has these fields, they will not be overwritten.

Fixes (the rest of) #96.

Don't reset the sortKey unless actually switching tabs

Creating a new annotation or page note would reset the sortKey for the
sidebar to the default, because doing so can trigger a call to
`selectTab`.

This change ensures that we shortcut the state update if we're already
on the correct tab, and don't update `sortKey` in that case.

Sort notes tab by date

This commit prevents page notes from being sorted by "Location" (i.e.
document location), a meaningless property for page notes, which would
result in them being sorted unpredictably.

Instead, we define a default sort key and a set of allowable sort keys
for each sidebar tab. When switching between tabs, the sort key is
updated to the default, and the set of allowable sort keys updated
depending on the tab.

This results in page notes being sorted (by default) in ascending order
of their most recent update. Using "updated" rather than "created" is a
bit dubious, but changing this requires a bit of care to avoid strange
behaviour on the stream, so I've left that for another time.

N.B. As implemented, the sort key on each tab will be reset to the
default every time the tab changes. This is less surprising than
preserving the sort key across tab switches, and doesn't involve any
requirement to remember system state across tab switches. We can also
revisit this in the future if it seems wrong.

Fixes #96.