Added a warning for 'while' loops over certain constants.

[reviewed by David]

This was motivated by my work on updating the existing code base to
the new task intent/capture for parallelism semantics (both in the
works, not committed to the repository).

Generate a warning when the condition of a 'while' loop is a 'const'
variable because we expect such loops to be infinite by mistake in
most cases. This warning can be turned off with --no-warn-const-loops
option.

Added a test case.

Discussion:

* The warning will be generated even when the constant is 0/false. In
general, the compiler won't know if that's the case, e.g.  if the
constant is a config or a result of a computation. Still we think
at the moment that the warning is worth issuing in most cases.

* The warning will not be generated if the loop contains a break,
return or yield statement. In these cases it is less likely
that the loop is infinite.

* Future work: generate the warning if the condition is a constant
expression, e.g. c1 != c2. Other fine tuning is also possible, e.g.
do not suppress the warning if the loop contains a break/return
under a condition that's false.

* The warning will NOT be generated when the condition is a param.
This is because there are several 'while true' loops in our code base,
where termination is taken care of separately. This makes us think
that while loops over a param are less likely to be infinite by mistake.

* Brad has another suggestion: Rather than thinking of the --warn-const-loops
flag as a bool, we could conceive of it as a flag with multiple levels
where the simplest interpretation of the levels might be:

        2 - suppress all of these warnings
        1 - warn for const expressions only
        0 - warn for param and const expressions

Although it still seems a little counterintuitive that params should
be less likely to generate a warning than consts (even though
practically that seems like the right decision). So maybe these three
levels aren't as much of a continuum as the levels suggest; and/or
maybe a bitmask is really what's needed.

* The test
   if (innerCall->numActuals() == 1)

does not have to be an assert. My argument is: if this condition
fails, we may miss a warning, but these warnings are incomplete
already, so that should be OK.  If it is incorrect to have !=1 arguments,
then something else, not checkConstLoops, needs to issue an error.

* It seem natural to mark _cond_test methods with a flag, then
test that flag instead of
  innerCall->isNamed("_cond_test")

I started converting this to a flag, but it was still not making sense
to me because:

 - "_cond_test" is going to be invoked in a 'while' regardless of
   whether it has that flag or not (see build.cpp).

 - I have seen _cond_test in non-internal modules, esp. standard/Regexp.chpl.
   Allowing users to add _cond_test methods makes sense, sort
   of. Having them annotate them with pragmas doesn't.


git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@21919 3a8e244f-b0f2-452b-bcba-4c88e055c3ca