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.
Merge pull request #336 from bradcray/sorterator

First draft sorterator

[reviewed by @thomasvandoren]

This is a first draft of a sorterator -- an iterator that takes some
other iterator or iterable as input, captures it into an array, sorts
it, and yields the elements back out to the user.  The current
limitations in the implementation reflect limitations in the language:

(1) There's no particularly good way to constrain the formal type to
be an iterator or iterable;

(2) There's no particularly good way to declare the type of the
temporary array;

Also added a test that invokes the sorterator in three ways, one with
an array, two with invocations of iterators.
Rewrote fannkuchs to use unbounded ranges as originally hoped for

In investigating this syntax error yesterday, I realized that the
cause was not because the parser does not support unbounded ranges in
an iterator context (whew!) but rather that there's an ambiguity
between the upper bound being a domain literal and the curly bracket
that starts a compound statement (shoot!).  To that end, I found two
ways to work around the issue (parenthesize the unbounded range or use
the 'do' keyword) and updated the future to note it and to request
whether there might be a way to change the precedence table to "do
the right thing" (on the argument that domain literals do not make
good upper bounds for ranges).
Merge branch 'master' of https://github.com/chapel-lang/chapel into fannkuchUnbounded
Merge pull request #352 from bradcray/fannkuchUnbounded

Update unbounded Fannkuch TODOs and future

Rewrote fannkuchs to use unbounded ranges as originally hoped for
In investigating this syntax error yesterday, I realized that the
cause was not because the parser does not support unbounded ranges in
an iterator context (whew!) but rather that there's an ambiguity
between the upper bound being a domain literal and the curly bracket
that starts a compound statement (shoot!).  To that end, I found two
ways to work around the issue (parenthesize the unbounded range or use
the 'do' keyword) and updated the future to note it and to request
whether there might be a way to change the precedence table to "do
the right thing" (on the argument that domain literals do not make
good upper bounds for ranges).