Change name of _build_range to be more explicit

Splitting the _build_range functions into 2 functions: chpl_build_bounded_range
and chpl_build_unbounded_range. This is for the upcoming anonymous range
iteration optimization where we want a clean way to find fully bounded ranges
early in compilation.

Added a chpl_ prefix instead of keeping the single underscore since that's the
direction we want to move with internal functions.
Update .bad file and retire a future

iterInClass now passes so I am retiring the future.

enumerate now has an extra line in the output, but the test still fails.
I've updated the .bad file to match the current output.
Update errors for malformed param ranges

Add the fact that param ranges must be bounded to the error messages
Missed adding an ==0 for strcmp
Need to add an error case for invalid types on partially bounded ranges

Since all the range builders used to have the same name, and the partially
bounded ranges and fully bounded ranges took the same number of parameters, the
generic error case applied to unbounded ranges as well. It no longer does since
the names are different so adding an error case.
Split up builders for unbounded ranges

Instead of having:
 - chpl_build_bounded_range
 - chpl_build_unbounded_range

we now have:
 - chpl_build_bounded_range
 - chpl_build_partially_bounded_range
 - chpl_build_unbounded_range

It seemed worthwhile to split the builders up further to be able to identify
partially bounded vs completely unbounded ranges. It doesn't feel worthwhile to
split up the partially bounded into low and high bounded (though it'd be easy
to do in the future if we change our minds.)

If you have a range like "1.." it feels more natural to call it a partially
bounded range instead of an unbounded range. I suppose it could be called a
partially unbounded range, but that feels strange. Unbounded implies ".." to
me, so it makes sense to split out the builders at the very least to avoid any
confusion.
Merge pull request #1010 from Kyle-B/kb-test-system-improvements

Update .bad file and retire a future

iterInClass now passes so I am retiring the future.

enumerate now has an extra line in the output, but the test still fails.
I've updated the .bad file to match the current output.
Update REGRESSIONS for 09-12-2014
Update REGRESSIONS for 15-12-2014
Merge pull request #1012 from Kyle-B/kb-regressions-12-2014

Regressions update for the week of 08-12-2014
Merge pull request #1003 from ronawho/change_build_range_signature

Change name of _build_range to be more explicit

[ok'd and suggested by @bradcray]

Split _build_range into:
 - chpl_build_bounded_range
 - chpl_build_partially_bounded_range
 - chpl_build_unbounded_range

This was motivated by the upcoming anonymous range construction elimination
work. I need a way to determine if a range is fully bounded immediately after
parse time. The checks that I was doing were restrictive and ugly so this
allows me to simply check for the appropriate builder based on name.

Added the chpl_ prefix to the builders since we're trying to move away from a
single underscore to indicate a Chapel-reserved word.

Also updates error messages for malformed param for loops to indicate that
param for loops only work on bounded ranges.
Alphabetize the list of scripts in util/README
Merge pull request #1014 from Kyle-B/kb-alpha-util-readme

Alphabetize the list of scripts in util/README
Merge branch 'master' into addIgnoreNoinitFlag
Fix errors with strings and complexes by always allowing noinit in module code

This is a bit of an artifact of how default values are implemented in the
modules.  There are some _defaultOf functions which must define an instance of
that type in order to initialize it.  Obviously these cases need to skip default
initialization for that instance or infinite recursion will occur.  Our
intention moving forward is that types will define their default through the use
of constructors, which would remove the need for noinit in these cases, but
since we are not there yet, it is necessary to ignore --no-use-noinit in the
provided module code.  While a bit heavy-handed, this is a reasonable approach
to take because the internal modules and standard modules should be considered
an implementation detail - steps taken to ensure their operability in all
circumstances should not be breakable by user code and compilation actions, or
our implementation would be incorrect.

At this time, there is no use of noinit in the module code solely for
performance (though as an implementation detail, it would not be unreasonable to
ensure noinit was always honored for that use).
One more test change

The test compflags/lydia/noUseNoinit/noinitSkippedCase.chpl specifically intends
to test the default and alterred behavior in regards to the --no-use-noinit
flag.  Throwing the flag with start_test alters the test's behavior and
circumvents its purpose, so skip the test when the flag is used.

I did not add a similar skipif to execflags/sungeun/about, because I don't think
we intend to run nightly --no-use-noinit testing (at least, not yet).  The
skipif file for that test seems to consist of flags we use for nightly testing.
If someone wishes to run this flag over the whole test suite, they should know
it might fail.

I also did not add a similar skipif for functions/hilde/defaultOf/precedence or
functions/lydia/userDefinedDefaultFunction/*, though these tests depend on
noinit to work.  My reasoning here is that their dependence on noinit is related
to their implementation, and since we intend to alter the implementation of
default determination to utilize constructors rather than the _defaultOf
function, it is important that these tests get noticed as still breaking with
--no-use-noinit when the implementation has changed.