Overhaul view and sort behaviour.

Sending the "more_hits" message when no past data filter has been
configured results in an exception in the backend and disconnection
of the socket.

Re-introduce the flash messages when attempting to reply to and
share unsaved annotations. Doing so is better than hiding them
because hiding them results in newly created annotations changing
layout when the id is returned from the server.

The view data is up-to-date with whatever the user entered already
and a re-render will happen again when the permanent id and timestamps
return from the server anyway.

I acted too quickly on these edits. I can squash them up.

Reduce the template logic and remove a use of 'group:__world__'.

This is semantically clearer than checking whether the tool is
highlight.

The threadFilter only needs to be tracking the single message in
the container. It is the deepCount that aggregates the results.
There's no longer any reason to cache a __filterResult.

Small style tweaks to the view-sort-overhaul branch

We can still make page comments even when in highlight mode so don't
save these until the user has a chance to edit.

I had foolishly added an angular.noop and then @gergely-ujvari did
the same, but that doesn't work because angular isn't guaranteed
to be loaded outside our sidebar.

This was part of an earlier card refactor but was put aside until we'd
tested it with the text diffs. These have been removed for the moment
so it seems like a good time to try this style out.

This makes it consistent with the annotation timestamp. The next step
is to make all actions focus when the card is hovered.

Move the edit and delete actions back down to the bottom of the
annotation alongside the share and reply actions.

Improve the experience when searching and composing by adding a
freeze function to the thread filter so that edits can freeze their
filter in a deactivated state in order to always match the filter.
This change keeps edits visible all the time and keeps the reply
and show more counts accurate.

Make the annotation and thread markup a bit more semantic and use
this to tweak some margins now that the reply count is below the
actions.

Drop the "<nobody>" placeholder for unattributed annotations and
instead just opt not to show the username or privacy and highlight
indicators.

Change the markdown directive to use an attribute and tighten up
the collapsed thread styles.

Rather than continuing to track the message counts in the thread
controller, make a separate deep-count directive that exports a
getter / setter from its controller that can be used to query and
increment counters that bubble aggreggations up to any deep-count
directive above.

Instead of firing a `threadCollapse` event when threads collapse
and canceling it from the annotation directive when the annotation
is being edited, the deep-count directive is used to track the
total number of messages in a thead, the number of matches found
by the thread-filter directive, and the number of annotations that
are being edited.

Remove most of the injectables from the thread controller and handle
more of the DOM-specific bits in the link function. The controller
becomes even simpler, but the directive needs tests now.

Create a new directive, threadFilter, that leverages the deep message
count feature of the new thread directive, using the searchfilter
and viewFilter services to keep track of the threads that match the
search filters in real time.

Close #960
Close #1109

Rather than traversing all the descendants at every digest of every
level of every thread, propagate updates from leaf nodes to parents
by giving each thread access to its parent thread controller. Digests
are only ever performed at the top level and are debounced so that
during progressive rendering of threads the number of digests is
greatly reduced. Some adhoc experimentation yields a 50% reduction in
digests during thread rendering on top of the performance gain by
not traversing descendants in `messageContainer#flattenChildren` calls
on every digest.

To accomplish the debouncing, the render service now returns a cancel
function making it have the same signature as `requestAnimationFrame`.

Card emphasis on highlight hover isn't supported by the sidebar
right now and we no longer disable annotating in the sidebar.

After I changed it so that it took a callback rather than a scope
the data parameter became rather useless.

Make changes to allow multiple top-level drafts, drafting before
authenticating, keeping drafts while performing page searches,
and replying to search results.

- Factor out the userAuthorize option passed to the Permissions
  plugin into a local function in controllers.coffee.

- Only load the Permissions plugin when logged in so that the
  plugin options do not leak information about the last logged in
  user and unattributed drafts have no user or permissions field.

- When switching to highlight mode, show the sidebar and flash an
  info message informing the user that they will need to log in
  before annotations are saved, but don't prohibit highlighting.

- Simplify the logic in the guest for highlight mode by offloading
  work to the annotation controller. The "inject" property is no
  longer needed. The annotation controller saves drafts of highlights
  if they have no user and persists them to the server as soon as
  the user is set.

- When logging in, the app controller simply loops through all the
  drafts are publishes 'beforeAnnotationUpdated' to give the
  Permissions plugin a chance to fire.

- When initializing the Store plugin, don't perform any search at
  all when not logged in. This change makes "single player" mode
  work even before logging in.

- Allow hiding the sidebar when editing. Simplify the guest code
  that no longer needs to track the sidebar state by listening for
  'annotationEditorHide' and 'annotationEditorSubmit' and the
  corresponding sidebar code that fired these. They're nonsensical
  now because there isn't exactly one "editor".

- Remove the concept of an 'ongoing edit' entirely, simplifying the
  sidebar code even further. Any number of edits are allowed and
  top level ones are not treated specially.

When the Store updates annotation data it only