Improve `require` setup for depth/delta and associated test spec

This is the last remaining todo on the pull request https://github.com/twitter/algebird/pull/354 for `CMS[K]` functionality, see my (now hidden by the GitHub UI) [comment in the PR discussion](https://github.com/twitter/algebird/pull/354#discussion_r20573866).

This commit improves the input validation of the key CMS parameters (delta/depth, eps/width) to prevent the user from mistakenly passing in values that trigger type precision errors.  Without this PR, the user may pass in values that lead to the generation of counting tables with delta == 2 billion rows (`Max.IntValue`).
Checking for `ceil <= Int.MaxValue` another option, and you make a good point regarding us checking for the practical limits of the CMS implementation (e.g. memory).  Hmm.

The reason I put the constraint on `delta` was to make it consistent with the theoretical, mathematical requirements regarding `delta`.  We perform such a `(0, 1)` range check for delta [in e.g. CMSParams](https://github.com/twitter/algebird/blob/develop/algebird-core/src/main/scala/com/twitter/algebird/CountMinSketch.scala#L146_).

I'd summarize the two approaches as follows (and I changed the text below while drafting this response as I reflected upon what I was writing :-P):

- The require on delta makes sure that the _mathematical_ constraints are not violated.  It also guards (partly) against type precision errors in practice when `delta` approaches 0, which subsequently can mess up `ceil`; here, the JVM may turn a very small `delta` into `0` which will lead to `Int.MaxValue` for ceil.  (Note that due to JVM precision limits for `double` we should never see a value for `depth` that is significantly larger than `710`; a double is not precise enough to see a resulting depth of, say, `10,000` given today's JVMs).
- The require on `scala.math.ceil` primarily guards against depth values that are non-sensical for _practical_ reasons, e.g. by us hitting type precision limits in the user's JVM plus (and this is a bit different) aspects like the memory footprint you mention, or the fact that the depth also determines the number of hash functions to generate.  It also guards partly against type precision errors for cases when `delta` approaches 0, but note that it does not guard against values of `delta >= 1`, which are illegal for CMS, too:

    ```scala
    scala.math.ceil(scala.math.log(1.0 / 60)).toInt
    res5: Int = -4  // <<< oops, negative depth!
    ```

(Another option would be to require that `0 < ceil <= Int.MaxValue`, which would prevent the latter from happening.)

One problem I see with using (only) `<= Int.MaxValue` is that we can't determine whether MaxValue was just barely reached (ceil correctly returned `2147483647`) or whether we reached type precision limits etc. (which trigger `2147483647`, too).  In other words, the `== Int.MaxValue` is ambiguous, and possibly too ambiguous if it's the only thing we're checking for.

However there's even more to it, which I realized when you talked about _practical_ constraints:

> perhaps we should for some delta that is actually non-sensical in that it would require more than MaxValue depth, which we can't do in memory.

The depth in CMS also determines the number of hash functions that are being used and, more importantly in this discussion, that must be generated.  Arguably, counting tables with a depth of `Int.MaxValue == 2147483647` may or may not be space-prohibitive already (and there's not a big difference between `2147483647` and smaller values like `2000000000` for that matter);  but a more relevant practical issue is the time required to generated `depth`-many hash functions.  It takes a looong time to generate 2B hash functions for CMS...

Where should we draw the line?

I'd tentatively suggest the following:

- We should keep the current `require` on delta in `(0, 1)`.  Optionally, we could put an additional `require` on `ceil <= Int.MaxValue`, although I'm not so sure about the latter the more I think about it -- see next bullet item.  But maybe this discussion is just about semantics;  I am fine either way.  The most important point is that there is at least _some_ validation.
- We should not put in `require` statements that validate non-sensical values purely because of _practical_ considerations (e.g. memory, time required to generate hash functions).  Hardware specs are different, machines get faster etc., which means it may be a slippery road.  Instead, we may want to update the scaladocs to inform the user what the impact of these settings are.  (IIRC you'd like to add some parameter guidance to Algebird anyways.)

What do you think?