Add overflow checks to bounded iterators

The default iterators do not support positively strided ranges whose last index
is max(indexType) or negatively strided ranges whose last index is
min(indexType). E.G "for i in max(int)-10 .. max(int)"

The above example turns into the following generated code

for (i=max(int)-10; i < max(int); i+=1)

and everything is less than max(int) so you would have an infinite loop.

Prior to c for loops our iterators didn't work for maximal ranges, but they did
work for the above example. They generated the equivalent of:
for (i=max(int)-10; i != max(int)+1; i+=1)

This relies on well defined integer overflow, which is not valid since integer
overflow has undefined behavior in c.

So while the new iterators aren't as capable as the old ones, they're more
performant, and don't cause undefined behavior.

To deal with this limitation I added a function that checks for overflow and
halts with a warning about them.

If a user really wants to iterate over such a range, I added a generalIterator
that works for any range including maximal ranges, but is terribly slow. To
avoid the performance cost the user can either rewrite their loop to avoid the
problem or try a wider type if they aren't already at the max size.

If they don't care about performance they can toggle
useOptimizedRangeIterators=false which is a big hammer that will use the slow
general iterator for all cases. This will lead to absolutely awful performance.
I can't think of a way to support such ranges in an optimal  fashion, but there
may be a better way to let users pick and chose what loops use the general
iterator.

The general iterator exposed some bugs in the c for loop implementation. Namely
that the break and continue labels were getting added to the wrong structure.

There are also some tests changes.

trivial/deitz/test_max_range_iteration
types/range/hilde/maximalRange

were tests that has ranges that the new iterators do not support. I updated
these tests to include the new error. I also added compopts so they tests the
unoptimized iterator. With bounds checks off and the optimized iterators being
used these tests would have infinite loops. We break to avoid this, so one
variation of the test captures the fact that these infinite loops will occur
(and are expected, although unfortunate.)

I also added a test that checks similar behavior as the previous two tests but
it does it for unsigned and signed variations for positively and negatively
strided ranges.