Need to cast stride.

The stride needs to be casted when the idxType is unsigned. This is still
correct even if the stride is negative because val:uint + -val2:uint is the
same as val:uint + max(uint)-abs(val2)+1

E.G. 1:uint + (-1):uint ends up being 1 + 255 which will end up being 0 since
unsigned integer overflow is well defined
Change bigStride to prevent overflowing

[ok'd by brad]

Quote from brad:

"Re-reading the history of this test, it was basically guarding against
some assumptions in the early range code that the idxType and/or stride
were 32-bits.  I think as long as the stride for this thing can't be
stored in an int(32), my earlier self would be happy.  For example,
maybe something like:

  1..2*(n/3) by n/3

(with some +/-1's in there to get a few values without hitting the
overflow issue?).  I can take this if you want."
Change atomictest to prevent range iterator overflow

[ok'd by brad]

quote from brad:

"Elliot says he doesn't think this is a particularly compelling example,
which I'd agree with.  We can just set n to be something smaller. "
Change fannkuch-redux-blc.chpl to use an unbounded range

This is identical to what brad did to the other fannkuch versions in
0b09c9534e5ef7bfabdd6040f76b1e4ea817a320

Just changing this test as well
Cast histoSerial iterator indices so they don't overflow the iterator

The iterator attempts to do something like "for 0:uint..length:uint by -1" and
so the last iteration will result in overflow since 0 -1 for uints will
overflow. This just casts the uint32 to int64s to prevent that
Update t2.chpl and t8.chpl to prevent iterator overflow

[ok'd with vass]

These tests create unsigned integer overflow in a couple of cases. They have
things like for 0..9 by -1. This causes overflow for the iterators. This just
changes the bounds to things like 1..9 by -1.