Significantly refactor plugin base classes--now with symmetry!

Refactor plugin base classes. It began while trying to figure out how to detect text vs. binary files, guess encodings, and provide file contents efficiently to the plugins. That led to a cascading minor restructuring of the FileToIndex and FileToSkim constructors, which FINALLY gave them symmetry (at last!) and enabled us to completely do away with the vexatiously difficult to conceptualize FileViewData abstract class. Now FileToIndex is a kind of FileToSkim, method implementations are shared, and all is right with the world. This plugin architecture is now starting to have pretensions of elegance.

Figuring out the text vs. binary condundrum opens the door to plugins which process binary files. So, for example, we could search for JPEGs by dimension or EXIF data or turn up debug-build binary blobs that reference certain symbols.

Sketched in fine detail (not included in this commit) the framework that calls into the plugins and handles parallelization of work. This shook out the specs for many plugin base class methods, telling plugin authors what to expect with regard to process boundaries and the resulting consequences of large objects.

Added a way for plugins to express their interest (or lack thereof) in each file, including a default implementation and a convenience method for limiting interest to text files. This saves a step in the urllink and buglink plugins and saves a mistake most plugin authors would have had to make and correct.