Improve the highlighting API.

Implement separate fields' highlighting as separate methods, because I can see other, more general kinds of highlighting someday existing. For example, if we had a filter that limited results to just folders and ran ``path:bar OR (folders:yes path:foo)``, I would expect the folder icon to swell up in results that matched the second clause of the OR. A highlighter for that would be likely to return a bool (meaning "yes, swell the icon"), not a string. It becomes less weird to have separate methods for separate signatures rather than multiplexing them all into one method and dispatching amongst behaviors with a highlight_field attr.

A bonus (but not a decision-maker) is that a single filter can once again highlight multiple fields. I cannot forsee any such cases.

Also, add a default of domain=LINE to the Filter class. We might as well have a default value there to save code in some cases, and this will be the most common one by far.
Make the build env the union of all the tree-indexers' envs. Whoops.
Implement negation for TextFilter.
Implement case-insensitive text searching.

Decided to add a second trigram index rather than try to brute-force the lowercase one with JS: the number of documents could easily get very large with negated terms, like if a user typed `-print` first on the way to `-print int`.

We'll probably need some length-based governors or something eventually regardless.
Delete references to trilite from the docs.
Remove dead old indexer_exports() and htmlifier_exports().
Bring developer documentation up to date with the new plugin API.

* Document everything about Filters in a Filter abstract class, which has eaten the old PathFilter example. Plugin authors can use this base or not, as they wish. I've backed off on the importance of the highlight method call optimization, in which highlight_path, for example, would not be called if it didn't exist. The optimization still exists, but filters obviously won't take advantage of it if they use this base class. Clarity of docuemntation for developers looking at the docstrings directly (rather than the Sphinx docs) took precedence over a theoretical speedup on the scale of a few function calls that I never even benched.
* Document `domain` and `name` in Filter. Moved all attr documentation to ivar directives so I wouldn't be forced to provide a default value for `name`, potentially hiding plugin bugs.
* Took the uninformative word "Construct." out of several docstrings. It was there to technically fulfill PEP 257, but it made the Sphinx docs read awkwardly once we started pulling in the docstrings.
* Described what refs, regions, and annotations conceptually are so plugin authors know which ones to implement.
* Stopped being so coy about the fact that ES is used on the back end. We didn't build a thick abstraction layer. There's no sense. I can't think of any other backend we could sub in that wouldn't require all the plugins to be re-engineered.
* Add graphviz plugin to Sphinx so we can have lovely little diagrams. Deactivate several unused plugins, especially intersphinx, which likes to hit the network during builds.
* Write documentation beyond the docstrings to put the new plugin system's components into context.
* Set autoclass_content so docstrings of constructors aren't ignored.
split type search from function sig search