GenericRange's covariance

Various fiddlings along the way helped to remind me why I hadn't made
GenericRange covariant in the first place, but I was able to deal with
all of those OK. Not so sure what to do about #2518:

http://lampsvn.epfl.ch/trac/scala/ticket/2518
regression in GenericRange's handling of "by"

Note to observers: Int and Long have sort of a weird relationship.
Since Long is higher-ranked than Int among the numeric types, a binary
operation involving Int and Long widens the Int. But the type system
has its own point of view and ranking is not a conformance relationship,
so List(5, 5L) is List[AnyVal], not List[Long].

What that means is that when you parameterize a covariant class with a
primitive type, suddenly mixing which was once seamless (like using Ints
where Longs are expected) instead turns your beautiful range of Longs
into some kind of frankenstein AnyVal producer.

So before I look too hard for ways to further abuse the type system to
address this, I have to ask: what are we getting out of GenericRange
being covariant? None of the Numeric types we ship are subtypes of one
another, or likely to be anytime soon, and the common supertypes aren't
usable for creating a GenericRange. It seems like the need is
theoretical but the punishment is concrete.