Faster filtering with fragmented annotations

[wjt]

Let me know if you'd prefer monolithic pull requests! The test data I'm looking at for this PR is here – you'll need to open it from tools/serve. The key commit message here:

If there are many spans of text for an annotation (many table cells,
say), previously the filter would be applied once for each span, and
matching annotations would appear n times in filter.annotations. In and
of itself this is relatively harmless, but filterHighlights then maps
back from annotations to highlights, and:

    for (var i = 0, len = filtered.length; i < len; i++) {
         highlights = highlights.not(filtered[i]._local.highlights);
    }

is ruinous. This change dramatically improves filtering performance on
my pet test case of big, overlapping highlights on a 5000×3 table.

I have mixed feelings about using a new identifier in _local for this,
but we don't have any guarantee that the id provided by the server is
unique, or even present.

I also have mixed feelings about setting the id in highlighter.js and
using it in filter.js, but the same coupling exists for
.data('annotation') already...

[wjt]

A nicer approach would be for Filter to track the set of annotations directly, rather than reconstructing it from the highlights. This would have other benefits as welll – for example, it wouldn't have to refilter all annotations just because a single annotation was modified – but it would be a more invasive change.

[tilgovi]

By the way, I think my latest commit on master will eliminate this suprious travis failures on pull requests. See what happens if you rebase.

[wjt]

Nope, the rebase didn't seem to help.

[tilgovi]

It would be nice to do this without coupling the highlighter and the filter with a private property. Any other ideas?