Allow C for loop operators to be user defined

Converts c for loops from:
  __primitive("C for loop", i, start, end)

to:
  __primitive("C for loop", initExpr, testExpr, incrExpr)

where init, test, and incr are either primitives or symExprs

This allows the relational operator to be user defined instead of forcing C for
loops to use <=.

To allow this we just update build.cpp to wrap the init, test, and incr exprs
with block stmts instead of buildling the init, test, and incr out of the
previous form and updating ChapelRange to create the init, test, and incr exprs
in the iterator.

Adds a function to AstUtil to check if a call is a relational operator and uses
that at codegen time to make the check for a relational operator reusable and
not just coded in codegen for c for loops.
Use c for loops in more range iterators

Use C for loops for unbounded ranges, and bounded/strided ranges.

This also adds an iterator to use when you know the stride is positive.
Currently the use must call this iterator themselves and it is used in an
optimized case for DefaultRectangular.chpl iterator.

I think it would be ideal if the stridable was an enum that was either
negative, positive, unknown, or none and then we could provide these optimized
iterators that would get used in a lot of other places. However, stridable is
used all over in ChapelRange, DefaultRectangular, ChapelArray, and all the
distributions so it would take a while, and I'm not 100% is possible yet. Plus
it would limit the by operator...
Clean up range iterators and switch to += and assign

Cleans up the iterators using C for loops in ChapelRange.

Also adds multiple user defined c for loops to userCForLoops tests that test
opEqual and nonOpEqual versions as well as some other relational and increment
operators
Clean up loop in DefaultRectangular and update comment
Add comment to clarify what's going on for c for loop generation
Update  explainInstantiation.good for printing a range

The DefaultRectangular iterator now forwards into ChapelRange instead of
implementing it's own loop so there's one more range instantiated now.
Fix indenting
Merge pull request #315 from ronawho/CForLoops-V2

Add V2 of "C for loops"

[reviewed by @daviditen]

Generate C style for loops for all iterators that forward to any range
iterator, not just the bounded+non-stride one. This includes arrays as
DefaultRectangular now forwards to a range iterator.

V1 of c for loops gave us c style for loops for the bounded+non-strided range
iterator. This brings us c style for loops for all range iterators and cleans
up the implementation of the c for loop primitive.

The primitive used to be: __primitive("C for loop", i, start, end, stride)

Now it is: __primitive("C for loop", initExpr, testExpr, incrExpr) where the
init, test, and incr can be symExprs, or other primitives.

This allows us to create arbitrary c for loops in the modules. Previously the
loops were forced to be a certain form by the compiler. They were turned into:
__primitive("C for loop", {i=start}, {i<=end}, {i=i+stride})

and there was no way to change the <= relational operator or specify the stride
expr, etc. This makes C for loops look uglier in the modules, but it cleans up
code in the compiler, and allows c for loops to be flexible. This seems like
the cleanest way to do this without changing the language to accept something
like:
__primitive("C for loop", {i=start}, {i<=end}, {i=i+stride})

directly in the modules.

In order to support this, the C for loop primitives and build.cpp had to be
adjusted to use the new form. There is also a new function isRelationalOperater
which is used at codegen time for c for loops.

Using the new form of c for loops the bounded+strided and unbounded range
iterators now use the c for loop primitive too.

C for loops were also switched to use the op= and assign operators. We didn't
use them before because of the ref temps they introduced, but the ref temp
elimination patch that went in recently allowed us to switch.

We also noticed that loops over an array didn't turn into c for loops.
"for a in Array" still generated a while loop. This is because of an old
optimization in DefaultRectangular that explicitly used a while loop instead of
forwarding to the range iterator. Brad sent me patch to correct this that
had a loop of the form:

for j in 0..size-1 {
yield theData(i);
i += step;
}

This created clean c for loops but it leaves you with two induction variables
and the backend compiler seemed unable to eliminate one of them. Ideally we
just want something like:
for i in 0..size-1 by step {
yield theData(i);
}

but then you forward to a less optimized iterator (where the c for loop uses the
!= relational operator instead of <=.)

To get around this I added a posStrideIter. It is an optimized iterator for when
you know the stride is positive. It is not intended to be used by users, but is
instead a stepping stone to give us a performant loop for positively strided
ranges until we have a more robust way to assert that the stride is positive at
compile time. While this is far from an ideal solution it's ok for now.