Email notification revisions

Use opaque focus highlights and tweak the rules.

Check cross site request token for WebSocket

http://www.christian-schneider.net/CrossSiteWebSocketHijacking.html

It may or may not be possible to change, but the way the current
highlighter slices the DOM when highlights overlap doesn't always
produce a structure where segments of larger highlights nest outside
segments of highlights that are entirely within their bounds. For
instance, structures like this may result:

    Spans boundaries:       [   ][[ ]][   ]
    Associated annotation:  A   ABA ABA   A

In this example, the range of A completely spans the range of B yet the
inner-most A span is completely wrapped by the B span, with no A span
wrapping them both. If A is the highlight with focus, it is not the
case that a CSS rule can simply neutralize the background color of B.
Therefore, the background color of the inner A span blends with the
background color of B, making the focus highlight less prominent than
it should be.

In this situation, the focus highlight can be guaranteed to be shown
in a clearly visible color by making it opaque. There may be colors
on which this is too low contrast, but until we can investigate other
options this PR makes the focus highlight color opaque to address this
issue.

Additionally, factor out a highlight mixin that makes it all a bit
more readable and consistent.

Fix #1766
Fix #1816

Chrome extension: update packaged PDF.js code to v1.0.907

Change highlight CSS for PDF.js

Put notifications behind a feature flag

Make the auth and settings sections of the app template into blocks so
that they can easily be overridden in inheriting templates. That makes
it possible to split the account and notifications settings into their
own templates without worrying about whether they are applicable for
downstream partners, who can now override the whole block rather than
the account template, for instance.

Pulse annotation cards when updated

Clean up the extension build script

In order to help the user notice updates arriving over the websocket,
this commit causes cards to pulse when they're updated.

If an annotation is part of a collapsed thread, then the pulse will
occur on the first visible parent thread.

Cards owned by the logged-in user will not pulse. This is primarily an
easy way of ensuring that cards don't pulse in the same view as they are
being edited (although it doesn't ensure this in all cases), but it also
makes sense more generally: users don't need to be notified of changes
they have made.

Fixes #1790.

This allows them to be included as a dependency without side effects.

Update PDF plugin

... to 46274663 (typed-packaging branch)

Un-minify dependencies

And only show the notifications panel for account settings when it is turned on

Fix #1762

Default to public visibility on annotations.

Fix #1799

development.ini: Add a development-mode session secret

Clean up Streamer.onmessage

- Fix "single player mode" filtering of highlights. It was assuming
  that $scope.persona was an object rather than a string.
- Remove multiple checks to ensure that payload is an array, the
  backend only sends arrays[1][2].
- Convert python style method docstrings to coffeescript comments.

[1]: https://github.com/hypothesis/h/blob/master/h/streamer.py#L562
[2]: https://github.com/hypothesis/h/blob/master/h/streamer.py#L488

Simplified auth plugin