Add better support for aggregating counters.

"counters" in this context are metrics like byte counters--monotonically
increasing counters maintained by something like the kernel.  They
sometimes reset.  Aggregating multiple counter metrics using SUM will
generate huge spikes whenever the SUM ends up going down (but not to
zero) and then back up... like when one or two of your nodes don't
report their counter values for an interval or two.

The special counter-aggregating behavior is triggered by specifying an
aggregation method of "counters" in a rule in aggregation-rules.conf.

Also fixed the fast_matches_8 thing to only go into effect when the
first segment of a metric path is >= 8 bytes.  That's still not optimal
(e.g would still break with an input_pattern like:
  (a|b|c|d|e|f|g|i).something.else
because the first segment is > 8 bytes, but each "piece" isn't.  But
it's good enough to be able to write unit tests with short metric paths.