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
Removing the TRIAGE file

A good idea, ultimately, it was unmaintainable.  Now using the
REGRESSIONS file for this purpose.
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.
Updating REGRESSIONS based on today's returns
Merge pull request #845 from bradcray/triage-sep-blc

Final commit in "tyrannical reign of triage"

I'm giving up my hold on triage for SC14 and Thanksgiving.
Take care of things for me, team!

New regressions
---------------
* test/link/sungeun broken everywhere due to skipif mods (hilde)

* manyThreads-inorder doesn't print full output	on linux32 when	it doesn't
  timeout

* recordWithRefCopyFns fails under baseline for	not-well-understood reasons
  (hilde)

Improvements
------------
* Colorado State OpenMP tests resolved	for OpenMP-less	darwin (thanks Ben!)

* Colorado State C tests resolved	for gasnet* by removing -nl (thanks Kyle!)

* externRecordLostFields resolved for prgenv-intel (thanks Lydia!)


Misc
----
* removed TRIAGE file because it became	out of control and I'm tracking
  in REGRESSIONS now

* added new gnu.darwin category to test gcc on darwin -- only errors are
  test/link/sungeun (b/c broken	everywhere) and	cfd-mini-c (darwin-specific)
  NB to Thomas: changed to inherit from darwin for the second reason but
  Ben's improvement above suggests that this wouldn't have been right...
  suggests perhaps having a darwin* category that both 'darwin' and
  'gnu.darwin' inherit from as we discussed.

* did a	final deep review of all mails that came in today.  I think only
  some of the xe configurations are missing.

* removed playground categories	since we're not	running	them anymore

* unified formatting of	recordWithRefCopyFns issue

* pidigits on llvm has been getting suppressed;	Thomas unsuppressed it to
  be more uniform with other cases so it showed	up as a	"new" failure.

* noted gbt/diten's ownership of memleaks/coforall

* re-sorted cygwin to match mail order

* removed jacobi from sporadic dist-block failures on assumption that
  Elliot's new timeout changes helped

* removed ugni/muxed section due to it not being recent	combined with
  the fact that	we're currently	only testing examples.
Add future to silence recordWithRefCopyFns.
Merge pull request #846 from hildeth/futureRWRCF

Add future to silence recordWithRefCopyFns.
Added .notest to m-lsms.par-forall.future
Merge pull request #847 from vasslitvinov/add-notest-to-m-lsms.par-forall.future

Added .notest to m-lsms.par-forall.future

This .future has been creating noise in nightly testing since I added it a couple of days ago.
Last night it had a false positive in the default configuration.

SO I am making it a .notest, to avoid further noise in nightly testing.
This is a poor-man's solution to the situation, I just do not have
any better ideas, given that this test is not a high priority for us.
The serial-forall variant, which passes, is still being tested as
  m-lsms.chpl
Do not test lulesh with sedov15oct.lmesh under valgrind.
Merge pull request #848 from vasslitvinov/do-not-test-large-input-for-lulesh-valgrind

Do not test lulesh with --filename=lmeshes/sedov15oct.lmesh under valgrind.

* Change .execopts from a symlink to the release version
to a regular file, eliminating the line with the above option.

* Remove .timeout, as I expect the remaining .execopts
to execute quickly even under valgrind.

Testing for sedov15oct.lmesh takes about 20 minutes in the nightly testing.
Brad believes that it is unlikely to uncover any issues
that testing with sedov2cube.lmesh wouldn't.
The latter testing remains enabled and takes much less time.

Unfortunately with size=2, only the boundary conditions are computed.
Ideally we would also test with an input file where the size is larger.
At the moment this is not done because there are no such input files
in lmeshes/ subdirectory.