refactor query compilation and matching

Most importantly, this changes the way that the query AST is represented
between GEQL compilation and ES query construction. The
Query.compile_patterns() method (now Query.compile_pattern(), since it
yields a single pattern tree) creates a tree of tuples where the first
element of the tuple is the name of the operation to be performed, and
the remaining elements are arguments to that operation. Arguments may be
sub-tuples representing more operations. For an example, see the
method's docstring.

This also adds to the possible operations that can be represented. Since
the GEQL behavior for "tag=val", "tag=", and "=val" are all fairly
different, I've given them different operation names at compile time so
that later evaluation or ES query construction can be dispatched more
easily based only on the op name. Same with "tag:val", "tag:", and
":val". "negate" is split out into its own operation as well. "And" and
"or" operations are added, as they'll soon be useful.

A Query's 'compiled_patterns' attribute (now 'compiled_pattern') no
longer associates compiled query terms with the original GEQL term from
the user, since it was somewhat messy to do so and I didn't really like
the "if you have twice the exact same "word" (ignoring leading '!'), the
last one wins" behavior.

Tests were adjusted to match the new query AST structure.
allow anchoring regex searches

This allows the use of "^" and "$" in GEQL regex searches, and ought to
make some results less confusing (terms that were not intended to be
part of the regex are re.escape'd).
automatic unit derivation

When an explicit "unit=" term with a per-unit-time denominator is
included in a GEQL query, graph-explorer will now widen the search to
include data sources with that unit /or/ any other unit that appears to
be compatible with it /or/ any unit compatible with the numerator unit.
If a datasource is found matching the numerator unit, Graph-explorer
will automatically apply a derivative function to change it into a rate.

Data sources with target_type='counter' will be automatically graphed as
a derivative, to show a rate, unless a contradicting explicit "unit="
term was included in the query.

The conversion machinery here is also capable of applying an integral
transformation to get from "unit/time" to "unit", but this is currently
not enabled as (a) I'm not sure if it would be confusing, and (b) I'm
not sure it would be useful, and (c) it would probably make most ES
queries slower with all the extra units it would search for.

Tests extended to allow for the new behavior.