When displaying a standalone annotation page for replies, display the
entire conversation thread which that reply is in, including the
original annotation.

Previously standalone annotation pages for replies were broken because
only the reply itself was fetched, the the existence of the top-level
annotation was inferred from the reply's `references` field but because
it was missing, a blank "Message not available" card was shown instead.

Showing the entire thread fixes this problem and also allows the user to
see the complete context of the conversation.

Also refactor the tests to be less tied to the implementation details of
the class and expressed more in terms of what the view does from a
user's point of view.

Fixes #3367

Add a NIPSA service to replace h.nipsa.logic

Allow admins to toggle specific features for a features cohort

`selections()` tried to listen for a 'ready' event on the DOM Document
object. The 'ready' event however is jQuery-specific however so that
never gets triggered.

Instead change the `selections()` function to perform an initial check
for a selection on the next tick and emit a null|DOMRange.

Fixes #3452

Make the styling of quoted snippets of the page consistent with the
styling of block quotes in annotation bodies.

The styling for `<del>` and `<ins>` elements in quotes has been removed
because it is not currently used.

Fixes #3435

Load annotations from DB for /api/search

Set the annotation cursor to a pointer for annotation cards to indicate
that it is clickable (it scrolls the page to that annotation) except for
the body which has a text cursor to indicate that the text is
selectable.

Several places in the <annotation> component assumed that the `tags`
field was an array, as did <tag-editor>. The `tags` and `text` fields
are always set by the server for annotations received from the API but
are not set by Annotator when creating new annotations in the page.

It would be better to initialize all of the required fields for
annotations when they are loaded into the app rather than in the
<annotation> directive. For now however keep the initialization of all
required fields in the same place.

This fixes an error when saving new annotations.

Do not use query property in Feature.{all,remove_old_flags}

Do not use query property in Subscriptions.get_subscriptions_for_uri

Remove query property usage in h.groups

Extract tag editor into separate component and update ng-tags-input

This fixes some issues with Angular 1.5.x.
See https://github.com/mbenford/ngTagsInput/blob/master/CHANGELOG.md

Fixes #3324

As part of an effort to simplify the <annotation> directive and make
testing easier, split this out.

Pg cleanup

Add options page to extension, allow disabling badge

The idiomatic way to create derived data structures from data in the
Redux state store is to do:

  derivedData = transform(select(store.getState()))

Where the `select` function extracts the relevant fields from the state
and the `transform` function then computes the derived data. Both
`select` and `transform` can be trivially memoized to avoid unnecessary
recalculations.

This simplifies `root-thread` by avoiding inheritance from EventEmitter
and in future will make it easier to avoid rebuilding the thread if none
of the relevant application state has changed.

Do not use query property in User.get_by_username

Extract timestamp out into its own component

The util.createDirective() test helper assumes that directives have
controllers and reports an error if it fails to find one.

The simplest solution is just to add no-op controllers to the affected
directives.

This makes it easier to test the refresh logic directly and decouples it
from the rest of the annotation display.

This brings support for lifecycle hooks which get called when components
are mounted, when their inputs are changed and when they are destroyed.

See https://github.com/angular/angular.js/commit/9cd9956d

Angular patch releases have historically been pretty safe WRT breaking
changes, so this loosens the version strictness slightly.

Rather than imperatively adding a 'keydown' event handler in the
<annotation> link function, use `ng-keydown` to set up an event handler
instead.

With this we no longer need a link function.

Persist in-place mutations of annotation tags and extras

Do not use query property in Blocklist model

Remove path for local pdf files.

Currently, when annotating a local PDF, the `file://` URL will be submitted to the server.
It is not appropriate to submit local file paths to the server.
Since entries in document.link should be URIs, omit the URL in the case of local files.

https://trello.com/c/K8t2kl9m/331-don-t-save-file-urls-in-document-metadata
53725fd

Do not use query property in Token.get_by_{userid,value}

Add Hypothesis-driven property-based tests for query builder

Use PDF fingerprint as primary search URI for PDFs instead of url.

The `actual` value is always the first argument to `assert` functions.

Also add an explicit separate test that checks that PDFMetadata
functions resolve immediately if the document is already loaded.

Consider the following situation:

- A PDF with fingerprint (F) exists at multiple URLs (U1, U2, ...)
- A user visits the PDF at U1 and annotates it
- A second user visits the PDF at U2

Prior to this commit, due to the way document equivalence for PDFs
functions, the annotations made at U1 will not be loaded, because the
initial search is made for U2 only.

(If the second user subsequently makes annotations at U2, and then
reloads the page, the annotations made at U1 will then show up, as the
association between U2 and F will have been made).

This commit improves the situation here by treating the PDF fingerprint
as the "primary URI" for the document, much as we treat <link
rel="canonical"> URLs as "primary" if we find them in an HTML page.

This means that the initial search will be made for the fingerprint F,
which will match the annotations made at U1.

For more, see:

  https://trello.com/c/DVUemKwi/329-use-pdf-fingerprint-as-primary-search-uri-for-pdfs

In order to make it easier to change the document metadata retrieved for
PDFs, this commit moves the code responsible for extracting that
metadata into a separate (tested) service.

We also remove our reliance on the `PDFViewerApplication.loading` which
was removed from the bundled version of PDF.js in August 2015. Instead
we simply check to see if `PDFViewerApplication.documentFingerprint` is
available. If not, we listen for the first 'documentload' event before
extracting metadata from the `PDFViewerApplication`.

Add edit view for feature cohorts

Remove old features from FEATURES_PENDING_REMOVAL

Load annotation from DB in streamer

Add non-nullable and default values to annotation.extra

* Implement new design for hovered conversation threads

Implement the new design for hovered replies from
https://trello.com/c/aXCXxzx2 .

The most visible effect is that conversation threads have a grey
background when hovered.

In the process of implementing the new styling, there is some cleanup
of the CSS:

 * Use `--reply`/`--top-reply` modifier classes on <annotation> and
   <annotation-thread> elements to style annotations, top-level replies
   and nested replies differently. This makes the CSS simpler and
   reduces the risk of unexpected side effects that come with descendant
   selectors.

 * Rename `thread` CSS classes to match the name of the component
   that they are used in, `annotation-thread`.

* Move 'annotation-unavailable-message' styling to app.scss

This class is used in the root template (viewer.html) not the
<annotation-thread> component.

* Darken expand/collapse toggle arrow only when annotation itself is hovered

Darken the expand/collapse arrow when an annotation is hovered but not
when its replies are hovered.

* Remove no-op CSS class

The `clear: both` styling had no effect because <annotation-thread>
is now using flexbox rather than floats for layout.

* Do not show 'Hide replies' link for replies

For replies there were two different ways to collapse the annotation
card, the expand/collapse toggle arrow and the 'Hide replies' link.

Removing the 'Hide replies' link avoids having two ways to do the same
thing and makes the cards look cleaner.

* Remove the light grey background for hovered replies

Following design review, remove the grey background for hovered replies.

* Make rendering of dashed lines to the left of replies better in Chrome

Previously the dashed line started at the top of the <annotation-thread>
component and the top part was covered up by the thread expand/collapse
toggle.

In Chrome the alignment of dashes within a dashed border varies as the
height of the element changes [1]. Therefore depending on the height of
the reply, this could result in the visible part of the line below the
collapse/expand toggle starting at either a gap or dash in the line.

By instead moving the dashed line to a separate element which is
positioned beneath the expand/collapse toggle, the first visible dash in
the reply line always appears in the same place and is aligned correctly
with the annotation content to its right.

[1] See http://www.impressivewebs.com/comparison-css-border-style/
    for a visual representation of why this is done.