Add trigram extraction machinery from trigrammer branch.
Remove build_tree(), which was meant to use the stdlib's regex parser.

It turned out to be easier and more flexible to write our own parser than to figure theirs out.
Remove trigrams(). ES will do this for us; we have only to extract static strings.

And the longer the strings we extract, the better: ES's positional indices will make us even more selective than re2's nonpositional ones.
Push the trigrammer toward getting the FREE method working.

That way, we'll at least have something we can deploy, even if it isn't quite as smart as re2's full-on Cox method.

What remains to be done is to implement a visitor which spits out a JS-dialect regex and to remove strings from the SubstringTree shorter than 3 chars.

* Get simplified() to a serviceable state. At the moment, it eliminates nodes having only 1 child. This is good enough to let us distinguish interesting regexes from plain old strings, for the purpose of deciding what kind of ES query to build in PathFilter.
* Relieve the trigrammer of the responsibility of actually creating trigrams. ES is good at that. (Remove TrigramQuery and its duplicate And and Or subclasses.)
* Add glob_to_regex().
* Move regex_grammar near its visitor.
* Fix visit_quantifier(), which didn't work. Covered by test_not_coalescing_over_uselesses.
Sketch a PathFilter that uses the regex machinery to handle globbing.

* Add case-sensitive trigram fields for path.
* Add es_regex_filter(), which we can use for full regex queries too.
* Add a PathFilter whose callees aren't done yet and which needs highlighting but is complete enough to show what lower-level things we need to build.
Make test data longer in trigrammer tests so tests remain valid when we start optimizing away short ngrams.
Make empty top-level nodes simplify down to ''.

This should make filter logic easier, since there's now only one representation of a null query.
Remove some functions we're not going to need anymore.
Filter short ngrams out of SubstringTrees.
Remove dead _coalesce_strings().

(I wanted it in the history in case we need it for Cox.)
Bring some comments up to date.
Add trigram extractor, and whip it into shape. Sketch PathFilter. Close #325.

From the PR:

In order to do regex queries, we need to extract static substrings from the users' regexes. We then bang those against trigram indices in ES to (hopefully drastically) narrow down the document set we need to examine. Finally, we run the actual regex against those.

Previously, on a "trigrammer" branch, we were extracting actual trigrams from the regex. It turns out we don't need to do that: ES is more than happy to split longer strings into trigrams itself. In addition, that gives us a selectivity boost: the relative positions of the trigrams is something ES can deliver. Thus, we here take the old trigrammer machinery from the "trigrammer" branch and adapt it to return longer strings.

The most interesting work in this PR is the simplified() method of SubstringTree. This takes a tree of boolean nodes (Ands and Ors and, at the leaves, strings) and does some easy simplifications. For example, the regex `yo|hello|there` would emit `Or(['yo', 'hello', 'there'])`, simplified to `Or(['hello', 'there'])` since "yo" is too short to be any use against a trigram index. Ands come into play when there is a wildcard of some kind that we can't (or aren't yet smart enough to) make use of between two other, nonoptional strings: for example, `hello+ there` might become `And(['hello', ' there'])` (or `And(['hello', 'o there'])` if we were really smart.

es_regex_filter and PathFilter, the other attractions, are sketches, not yet intended to be complete, but they are useful as an illustration of why the lower-level stuff is the way it is, so I want them committed together.

I also deleted a lot of dead code. There still remain some parts of the Cox method I half started on; they live because I do intend to go in that direction eventually, probably post-launch, to enable us to extract strings more intelligently.