GH-345: Parameterize CMS to CMS[K] and decouple counting/querying from heavy hitters

_See the discussion in GH-345 for details on this pull request._

Note: This PR contains a "clean" fix plus regression tests for GH-353, i.e. the bug where heavy hitters are not correctly computed in CMS.

**High-level summary of this pull request**

* Parameterize `CMS` with a type `K` to decouple the item identifier type from hardcoded `Long`.
* Two traits `CMSCounting[K, C[_]]` and `CMSHeavyHitters[K]` to decouple counting/querying from heavy hitters tracking.
* Three implementations of these traits:
    * `CMS[K]`, which can only counting and estimate.
    * `TopCMS[K]`, which can count, estimate, and track heavy hitters.  The logic to compute heavy hitters is pluggable, see below.
* A trait `HeavyHittersLogic` (for the lack of a better name) that controls how a CMS that implements `CMSHeavyHitters` tracks heavy hitters. This decouples the "core" Top CMS implementation from the heavy hitters sub-functionality.
* Two implementations of this trait: `TopPctLogic`, `TopNLogic`.
* Monoids and aggregators for `CMS`, `TopPctCMS`, `TopNCMS`.
* A lot of new/improved CMS documentation.
* An updated spec/test suite, including regression tests for GH-353.
    * Includes tests for `K in {Short, Int, Long, BigInt}`.
    * Includes a "negative test case" that documents the `++` order bias of top-N CMS.
* A Caliper benchmark for CMS.  Also adds a README to algebird-caliper.

Please take a look at the code and let me know which further changes you'd like me to do so that this PR and thus the improved CMS implementation can be merged.

And many thanks for all the help and support so far!
Michael

PS: For the sake of this PR I decided not to squash individual commits into a single, big commit so it's easier to back out of changes you may not like etc.  I can of course squash the commits if needed once the PR code is approved.
I have done some further experiments this morning, maybe the findings will help a little.

I already added test cases that document the good as well as the bad behavior of depth/delta roundtripping: https://github.com/miguno/algebird/commit/9c02f1a2070e4675a1d871dfb59e5a0598391322.

**depth/delta**

>So we could just require the the val y = depth(delta(x));(y == x) || (y == (x + 1))` right?

Initially I was thinking the same, but my opinion has changed a bit based on today's findings.  I'd propose to add a new `require` statement for `depth` as follows:

```scala
require(0 < delta && delta < 1, "delta must lie in (0, 1)") // already in the code
require(CMSFunctions.depth(delta) != Int.MaxValue, "delta is too small and will cause math precision errors") // <<< new!
```
I argue that we'd prefer not to create a counting table with a depth of 2 billion (`Int.MaxValue1).  At the "inflection point" of the precision, our users would otherwise experience a sudden jump from a depth of 710 to 2 billion -- that results in a memory footprint (of counting table) that is many orders of magnitude larger as well as unnecessary.

What do you think?

**width/eps**

Here I discovered even more problems because of math precision.  That is, there are many `i` for which the true result is off by a small epsilon:

```scala
scala> scala.math.exp(1) / eps(39)
res171: Double = 39.00000000000001   // <<< ceil() returns 40 here, though we'd actually need 39
```
The effect of this is that you can't write (IMHO) a meaningful property test for width/eps because of all the many "special" `i` for which the test will fail because of precision errors.

I experimented with changing `width()` to use `round()` instead of `ceil()`.  This fixes this problem of width->eps->width roundtrip testing, but unfortunately the actual CMS tests start to fail (oops).  So this approach doesn't solve the problem.

Instead, I decided to add a `truncatePrecisionError()` method based on BigDecimal that essentially throws away small epsilons.  See https://github.com/miguno/algebird/commit/ba498d6bc4a58e1a1ad480ebecf379a2a6e5134d.  This change works reliably and all tests pass.