Move perf graph sorting to genGraphs

Instead of sorting graphs online, sort them when we generate the graphs in
gengraphs.

The sorting functionality is still on for the javascript code. Turning it off
will come in a later commit.
Stop sorting graphs online. Already sorted in gengraphs now
Call setColors for expanded graphs and multi configuration graphs

Set colors is still needed for graphs that will be expanded (to set the dashed
lines) and if multiple configurations are being displayed (also for the dashed
lines.)

Also I changed the graph titles for some of the compiler performance graphs
since they had identical names which screws up detecting which suite is
selected. I should add a check for duplicate titles.
Merge pull request #839 from ronawho/sort-graphs-in-gengraphs

Sort perf graphs' series in gen graphs

[reviewed by @Kyle-B]

This will have a pretty substantial impact on graph loading times, and will
allow me to rip out a bunch of the javascript functionality.

Sorting used to happen online with the expectation that we might have more
complicated sorting in the future. e.g. sort based on the average of the last
weeks data instead of just sort based on the most recent day.

This moves sorting to gengraphs and stops sorting online. The functionality to
sort online is still in perfgraph.js but I'll remove it later assuming
everything goes well.

The actual sorting in gengraphs is a little kludgy because it takes the csv
that is generated, parses that and then sorts it before printing printing out
the now sorted csv.
Initial attempt to optimize anonymous range iteration

When iterating over a range such as:
  for i in 1..10 do ...

we end up constructing a range and then getting it's low and high values out.
The range creation adds additional overhead that is not needed and it
obfuscates the loop from the backend compiler (it probably can't figure out how
the number of iterations even though the chapel compiler knowns it at compile
time.)

Ideally we want to generate
  for i in 1..10
as
  for(i=1; i<=10; i+=1)

This removes the construction cost, and should allow the backend compiler to
optimize/auto-vectorize better.

To accomplish this, this work replaces anonymous ranges with direct iterator
calls in for loops. Ranges are iterable because they have a these method. This
replaces the range with a direct call to an iterator. It essentially replaces
the code:
  for i in 1..10
with:
  for i in _opt_range_iter(1, 10)

the end result is that
  for i in 1..10
is now generated as:
  int64_t i;
  for (i = INT64(1); ((i <= INT64(10))); i += INT64(1)) {}
which is exactly what we wanted

This also handles anonymous ranges whose stride is known at compile time

E.G it handles
  for i in 1..10 by 2

and it will call into a more optimized iterator

if the stride is not known at compile time we don't do anything because we need
the range iterator to use chpl__diffMod

Not that this does nothing for aligned ranges, and doesn't handle cases such as
for i in 1..10 by 2 by 2 since it doesn't seem like a common case

The first attempt to do this was to replace the entire for loop with a c for
loop directly, but you can't do that for zippered iterators and figuring out
the type of the stride is really difficult and you have to insert calls to the
overflow checking and the general iterator.

A better long term solution might be to expand scalarReplacementOfAggregates to
includes ranges. That would allow all ranges to be optimized, including
non-anonymous ranges, and ranges that are used in contexts other than direct
iteration.

I still need to clean up the direct iterators, and make use of them from other
iterators. I also need to add bounds checks and the general iterator around it.