Accidentally using different types for the lower and upper endpoint produces a `ClassCastException` when validating that the lower endpoint isn't above the upper endpoint. This is a little surprising.

For example, the following:

```java
Range<? extends Number> range = Range.closedOpen(0, 1.0);
```

results in

```
java.lang.ClassCastException: java.lang.Double cannot be cast to java.lang.Integer
        at java.lang.Integer.compareTo(Integer.java:52)
        at com.google.common.collect.Range.compareOrThrow(Range.java:690)
        at com.google.common.collect.Cut.compareTo(Cut.java:77)
        at com.google.common.collect.Range.<init>(Range.java:349)
        at com.google.common.collect.Range.create(Range.java:155)
        at com.google.common.collect.Range.closedOpen(Range.java:189)
```

(In the actual code I'm looking at, the `range` variable is a function parameter that must accept numeric ranges of different types, so it's less weird than it looks here.)

Now, the range produced here _is_ completely invalid, and there's no way that the compiler can check this (because we can't express that the two bounds parameters must be the same concrete type, or at worst be mutually comparable).

However, it would be nice if `Range.compareOrThrow()` caught `ClassCastException` and returned a clearer message, or just chained the CCE onto the "Invalid range" `IllegalArgumentException` it can already throw.

I note that `Range.compareOrThrow()` has a "may throw CCE" comment, but the only place that this exception is mentioned otherwise is in the Javadoc for `Range.encloseAll()` and a comment in `Range.contains()`, both of which are talking about their function arguments.
* <tr><td>{@code [a..+∞)} <td>{@code {x | x >= a}}     <td>{@link Range#atLeast atLeast}
 * <tr><td>{@code (-∞..b)} <td>{@code {x | x < b}}      <td>{@link Range#lessThan lessThan}
 * <tr><td>{@code (-∞..b]} <td>{@code {x | x <= b}}     <td>{@link Range#atMost atMost}
 * <tr><td>{@code (-∞..+∞)}<td>{@code {x}}              <td>{@link Range#all all}
 * </table>
 *
 * </blockquote>
 *
 * <p>When both endpoints exist, the upper endpoint may not be less than the lower. The endpoints
 * may be equal only if at least one of the bounds is closed:
 *
 * <ul>
 *   <li>{@code [a..a]} : a singleton range
 *   <li>{@code [a..a); (a..a]} : {@linkplain #isEmpty empty} ranges; also valid
 *   <li>{@code (a..a)} : <b>invalid</b>; an exception will be thrown
 * </ul>
 *
 * <h3>Warnings</h3>
 *
 * <ul>
 *   <li>Use immutable value types only, if at all possible. If you must use a mutable type, <b>do
 *       not</b> allow the endpoint instances to mutate after the range is created!
 *   <li>Your value type's comparison method should be {@linkplain Comparable consistent with
 *       equals} if at all possible. Otherwise, be aware that concepts used throughout this
 *       documentation such as "equal", "same", "unique" and so on actually refer to whether {@link
 *       Comparable#compareTo compareTo} returns zero, not whether {@link Object#equals equals}
 *       returns {@code true}.
 *   <li>A class which implements {@code Comparable<UnrelatedType>} is very broken, and will cause
 *       undefined horrible things to happen in {@code Range}. For now, the Range API does not
 *       prevent its use, because this would also rule out all ungenerified (pre-JDK1.5) data types.