SI-4370 Range bug: Wrong result for Long.MinValue to Long.MaxValue by Int.MaxValue

Fixed by rewriting the entire logic for the count method.  This is necessary because the old code was making all kinds of assumptions about what numbers were, but the interface is completely generic.

Those assumptions still made have been explicitly specified.  Note that you have to make some or you end up doing a binary search, which is not exactly fast.

The existing routine is 10-20% slower than the old (broken) one in the worst cases.  This seems close enough to me to not bother special-casing Long and BigInt, though I note that this could be done for improved performance.

Note that ranges that end up in Int ranges defer to Range for count.  We can't assume that one is the smallest increment, so both endpoints and the step need to be Int.

A new JUnit test has been added to verify that the test works.  It secretly contains an alternate BigInt implementation, but that is a lot slower (>5x) than Long.