Disable clang build for travis for now. It fails to compile.

See failed build output here:

  https://travis-ci.org/chapel-lang/chapel/jobs/34771798
Merge branch 'master' of https://github.com/chapel-lang/chapel into filerator
Merge branch 'master' of https://github.com/chapel-lang/chapel
Merge branch 'filerator' of https://github.com/bradcray/chapel into filerator
Merge branch 'sorterator' of https://github.com/bradcray/chapel
Initial pass to switch from CHPL_MEM value of 'default' to 'cstdlib'
Changing sorter() to sorted()

Thomas pointed out that Python uses sorted() for a generator like
this, which also happens to be the first name I used before deciding
that it sounded like a boolean query rather than an iterator.
Followed up on reviewers' comments.
Moved preFold of tuple indexing into resolveTupleIndexing()
by Tom's request.
Merge pull request #324 from vasslitvinov/const-checking-for-loop-index-variables

Implemented const-ness checking for loop index variables.

Also changed how _indexOfInterest is detupled in certain cases.

There are various cases that needed to be handled,
the ones I considered are listed in

  test/statements/vass/index-variable-const-errors.chpl

The way I decide whether to set FLAG_CONST on the index variable
is based on isReferenceType() of _indexOfInterest and,
in the case it is detupled, on isReferenceType() of the
corresonding tuplel component.

Looking in the future: A solution based on FLAG_REF_VAR
would be preferred. Each index variable would be either
FLAG_CONST or FLAG_REF_VAR. FLAG_REF_TO_CONST would be
added to the latter if appropriate.

I set FLAG_INDEX_OF_INTEREST on temporaries to handle the case
of the index variables forming a tuple of a tuple, e.g.

  for ((i1,i2),a) in zip(my_2D_domain, myArray) ...

A tricky case is a zippered loop with a 'var' iterator,
and a single index variable, i.e. with no detupling:

  for myVar in zip(...) ...

Ideally we would like myVar(i) to be mutable for those
'i' positions that correspond to mutable iterators,
and const for the other positions.

Currently, in the above, myVar is considered 'const'.
I hope this makes sense.
All myVar(i) are mutable, however, because checking
accesses to const tuples is not implemented.

Another tricky case is a regular loop where the iterator
returns a tuple containing an array. I did not look
into this case specifically.


On how _indexOfInterest is detupled:

The compiler currently creates a generic detupling expression
_indexOfInterest(1) etc. during parsing/in build.cpp.

During resolution this used to get converted to

(A) PRIM_GET_MEMBER i.e. address of _indexOfInterest(1)
if that member's type is non-reference

(B) PRIM_GET_MEMBER_VALUE if the member has a reference type

This actually makes sense. For (B) the address is fetched from the tuple
directly. This transports a Chapel-level reference.
For (A), the compiler did not specialize for _indexOfInterest.
In general, it is unknown whetherh myTuple(i) will be used
as a reference or as a value, to the more general choice
is made, and later transformations deal with this somehow.

For _indexOfInterest, however, we know that (A) will
be constant, so will not be used as a reference, so
we can use PRIM_GET_MEMBER_VALUE directly.
However, we still need to watch out when the entire
tuple has a _ref type, e.g. _ref(int*2). This indicates
that the tuple comes from a tuple-yielding 'var' iterator.
It so happens that we need PRIM_GET_MEMBER in this case.

The same applies to chpl__followIdx because it serves
the same purpose, except in forall loops.

My motivation for this change is that I need it for my
upcoming forall intents.


TEST CHANGES

There were a couple of tests that assumed that index variables
are mutable. I modified them to comply with my checks.

Those tests seemed so convincing, however, that I feel
we should allows them optionally, e.g. using 'var' keyword:

  for myVar in ... // myVar is const
  for var myVar in ... // myVar can be modified

I filed a future for this. However, we may want to reconsider
whether the immutable should be the default.

A particular questionable case is iterating over tuple components
- should that be a 'var' iterator?

This resolves David's recent future on the subject. I augmented .good
because the compiler reports both const errors in a single pass.

This introduces a regression in

  types/tuple/sungeun/iteration/forall.chpl

because the code modifies a 'const' loop variable.
We need to see how to fix this.
Added sorting capability for filerator
Rewrote tests to do sorting more properly
Merge branch 'sorterator' of https://github.com/bradcray/chapel into filerator

Conflicts:
	test/studies/filerator/walk.chpl
Added more execopts variations to my walk test

Changed the default startdir to "." also.
Fixing bottom-up walkdir()

It turns out that my previous version of walkdir() had a bug
in the recursion which only showed up in the bottom-up case
which somehow escaped me in my previous commit.  This fixes
it by breaking the listdir() capability out into its own routine.
Changed old listdir() routine and test to findfiles()

Having created a listdir2() as a utility, and given that listdir() was
becoming less and less like something we'd export, created a
findfiles() routine implemented in terms of walkdirs() and listdir2()
which reproduced the behavior of the original listdir().

Next step, remove listdir(), rename listdir2().
Simple cleanup -- remove original listdir()

The original listdir() was well past its point of usefulness, so
removed it now that findfiles() replaced its functionality and
renamed listdir2() to listdir().

This also meant that the code put into the Filerator help module
(originally because it was in two separate places) was now only
used in one, so removed the helper module (which never worked
anyway) and moved its contents into listdir().
Moved serial glob/wordexp iterators into Filerator.chpl
A start at originally-proposed routine

Didn't get it working right, primarily w.r.t. files/dirs.
Also segfaulted.
Moved filerator code to modules+runtime

Everything still seems to work
Added test regarding following symbolic links

Because it turned out that I hadn't handled this case previously.