Use callables for "target_modifiers" functionality

This allows the pre-processing code a large degree of freedom in how a
target or graph is massaged before being sent off to the browser.
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.
Add some things Dieter noticed

- change name of test_regexing test method test_sum_by_buckets, since
  the test is really more focused on that and not regexing
- add a few more type conversion tests
- add a link to the Units and Prefixes page on the wiki in the unitconv
  module docstring
call ASTs ASTs, not 'patterns'

I think this hits all the places where the code used "pat" or "pattern"
in places which now refer to trees of AST tuples. Also,
Query.compile_pattern() becomes Query.build_ast().
assure that targets always have 'tags' set

historically at this point we didn't care so much about
the tags attribute anymore, as going forward we only needed
variables and constants to do the graph rendering.

but now this is important for target_modifiers to work that need to
inspect tags, such as the unit tag.
(we could also have them search in constants and variables but
that seems clunky, we could also return tags dynamically in the
Target object based on variables/constants but
this solution seems more clear)
bugfix: import warnings
Merge branch 'auto-derive'