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.