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.
Did you mean to say `depth(delta(i)) == i`?  Let me know if I misinterpreted your comment.

I think what you wanted to test is whether translating between the CMS parameters `delta` and `depth` is properly done by by the `delta()` and `depth()` functions, right?

However, `depth(delta(i)) == i` (for all `i > 0`) is more a test whether `depth` is the inverse of `delta()`.  And, if we were to test `delta(depth(i)) == i`, we'd verify whether `delta()` is the inverse of `depth()`.

Unfortunately, this is generally not the case.  See below.  Hence my question:  What would you prefer to do about the tests you were asking for, given the context below?

**depth(delta(i)) == i, aka "is depth the inverse of delta?"**

TL;DR:  This property is correct in theory but not in practice because of type precision limits.

```scala
def delta(depth: Int): Double = 1.0 / scala.math.exp(depth)
```

Theoretically, the image (i.e. output range) of `delta(i: Int)` is `(0.0, 1.0]` (see the plot: [plot 1.0 / exp(x) from x=0 to 10, y=0 to 1](http://www.wolframalpha.com/input/?i=plot+1.0+%2F+exp%28x%29+from+x%3D0+to+10%2C+y%3D0+to+1)).  In practice however -- because of type precision limits -- `delta` will begin returning `0.0` for all `i >= I`, and that `I` is `710`:

```scala
scala> 1.0 / scala.math.exp(709)
res39: Double = 1.216780750623423E-308

scala> 1.0 / scala.math.exp(710)
res40: Double = 0.0
```
That is, the `depth(delta(i)) == i` property is violated for all for all `i >= 710`:

```scala
scala> depth(delta(709))
res45: Int = 709

// for all i > 710, delta chokes because of precision limits.
scala> depth(delta(710))
res46: Int = 2147483647

scala> depth(delta(711))
res47: Int = 2147483647
```
(If you wonder why `2147483647 = Int.MaxValue` is returned:  `scala.math.log(1.0 / delta(710))` returns `Double.PositiveInfinity`, and `Double.PositiveInfinity.toInt` returns `Int.MaxValue`.)

Also, we `require` the CMS parameter delta (i.e. the value/parameter, not the `delta()` function) to be:

```scala
require(0 < delta && delta < 1, "delta must lie in (0, 1)")
```
Here I asked myself the question: What is the _smallest_ possible value we can pass in for delta, and what would be the corresponding and, by definition, _largest_ value for depth?  

```scala
scala> depth(0.1)
res149: Int = 3

scala> depth(1E-307)
res129: Int = 707

// Hey, here's the 710 again.
scala> depth(5.57E-309)
res146: Int = 710

scala> depth(5.56E-309)
res147: Int = 2147483647
```


Addressing your original comment, what would kinda work is a test like this, but this only tests the direction delta->depth.  But I am not sure about what value this test would add.

```scala
  property("roundtrips delta->depth") {
    forAll(Gen.choose(0, 709)) { (i: Int) =>
      CMSFunctions.depth(CMSFunctions.delta(i)) should be(i)
    }
  }
```

**delta(depth(i)) == i, aka "is delta the inverse of depth?"**

TL;DR:  This property is generally incorrect because of `ceil`.

```scala
def depth(delta: Double): Int = scala.math.ceil(scala.math.log(1.0 / delta)).toInt

// for demonstration purposes -- not used in CMS
def depth_no_ceil(delta: Double): Int = scala.math.log(1.0 / delta).toInt
```

A similar issue exists for `depth(i: Double)`, which returns integers >= 1 for its valid input domain (all rational numbers `i` with `0 < i < 1`, which is what we `require` in `CMSParams`).  Primarily because of its use of `ceil`, we have many output collisions, which means we can't roundtrip.  See [plot ceiling(log(1.0 / x)) from x=0 to 1,y=0 to 10](http://www.wolframalpha.com/input/?i=plot+ceiling%28log%281.0+%2F+x%29%29+from+x%3D0+to+1%2Cy%3D0+to+10).

As you can see, `depth_no_ceil()` works as expected (just for demonstration):

```scala
scala> depth_no_ceil(delta(10))
res106: Int = 10

scala> depth_no_ceil(delta(709))
res107: Int = 709

// Delta chokes for all i >= 710, remember?
scala> depth_no_ceil(delta(710))
res108: Int = 2147483647
```

**width and eps**

The same limitations exist for `width` and `eps`.

**Next steps**

Let me know what you would prefer doing here.