Since the token changes whenever the list of personas changes just
refactor the logic in the token watcher to cause exactly one search
to happen when the token changes without consulting a separate
property, simply by checking the tool state.

This reverts commit ca43ccc1d9559476f95c714c1b055194f03dd0c2.

These should have been added along with the rest in 8c7db59e05dd7757989f6b31a19edef6cfb686fd

Since the highlight code uses jQuery's .offset() we don't need to
factor in the wrapper offset.

Close #931

The root core of problem #1179 is actually an upstream problem. Our code is only necessary until we can consume the fixed version of annotator.

When we receive updated versions of existing annotations from the
other side of the bridge, not only merge those changes,
but announce them with the appropriate event, too.

Based on changes originally introduced here:
https://github.com/hypothesis/h/commit/1d4e9f32cc4f8c7db5ffdac7adad90e9cbf88db6#diff-5

In the past when we were switching users the previous user data has remained inside the Permissions.options.permissions object.
This way, our newly created annotations had all the previous logged in user's permissions in their permission list which wat totally wrong.
In this fix when logging in/out this options.permissions object is resetted too. (Along with the user)

Fixes #1179

Search each one individually. This was always the intent but the code
was wrong.

This is in preparation for adding these things to the site pages.

Close #1174

This eliminates the subscriber hack and allows us to use the check_csrf
view predicate in the future by making Angular send the header that
Pyramid expects.

Close #1172

And get rid of the resettable directive. Since Angular added the
`$setPristine` method, we can wrap the errors in a check that the
control is dirty.

This code doesn't do any DOM manipulation so its better kept as a
controller.

This simplifies the tests a little bit, maybe it will be more
robust???

Also seems like a useful thing to do anyway.

This reverts commit 28c48518c064b6c0769b43d7ddcdbbe89a169926.

Reverted until @csillag shows me why this is a significant win because
otherwise it is code here that has nothing to do with the toolbar.

More minor tidy of OSX docs

With the page search you can search for the username, but for redacted annotation the user filter gives back a null as a username, and we tried to convert this to lowercase()

Fixes #1160

Since, for document view to had to add the new annotation manually to the rootScope.annotations, we have forgotten to check whether is it a reply or not.
Now replies are not added. The original error also went away when the view(scope) was changed.

When we deploy as an extension the application baseURI is the URL
of the backend, rather than the extension. As a result, templates
are relative to this location. Even though we inline the templates
in the extension bundle, we have to ensure the compilation isn't
blocked by strict contextual escaping.

When we sacked the scope search facets and rely on rootScope.annotations the replies were no longer tested as possible search results. It is now restored.

This was causing a race condition on app startup. Now, the worst that
happens is the flash message shows in the sidebar.

If not doing this the rootScope.predicate etc. variables are not set and angular silently fails sorting

Fixes #1150

The rootScope.annotations was not refreshed when a new real-time annotation arrived, so for comments and document view we have to insert the annotation there manually

Fixes #1149

As for the sort the page search works with threads instead of annotations so the directive should look for either annotation or thread.message in the scope
Page search focuses annotations when it opens them.

Thx @csillag for the help

Originally page search was not prepared for the sort viewState, now it is.
For this, the applySort() was refactored to use the rootScope instead of the scope and produces both the predicate for the viewer and for the page search

Fixes #1148