Disable futures for cygwin

Cygwin testing takes a while and it doesn't seem to be much benefit of running
futures on cygwin.
Turn off cygwin testing for TooManyThreads.chpl

Cygwin doesn't allow you to set the number of threads, so this test is not
useful on cygwin.
Merge pull request #738 from lydia-duncan/tooManyThreadsFix

Turn off cygwin testing for TooManyThreads.chpl

Cygwin doesn't allow you to set the number of threads, so this test is not
useful on cygwin.
Send darwin regression mail to normal lists

Previously it was only sent to the all regressions list. The non-deterministic
errors have been cleaned up so it makes sense to send it to all.
Merge pull request #739 from ronawho/darwin-regression-mail

Send darwin regression mail to normal lists

[trivial, not reviewed]

Previously it was only sent to the all regressions list. The non-deterministic
errors have been cleaned up so it makes sense to send it to all.
Merge pull request #701 from ronawho/cygwin-futures

Disable futures for cygwin

Cygwin testing takes a while and it doesn't seem to be much benefit of running
futures on cygwin.

Future feature request from Brad that seems like a good idea: 

"I had a feature request thought for futures -- curious what you think. I think it'd be nice if, in addition to "futures on" and "futures off" there was a middle setting in which futures would be tested if they had a .skipif file. That way, if one had a future that was cygwin-specific, say, they could add a skipif to skip it on everything other than cygwin; yet the test would still be tested on cygwin (without testing all 500 other futures which are presumably independent of cygwin vs. linux64)."
Try bumping qthreads+gasnet timeout for low core count machines again
Merge pull request #740 from ronawho/qthreads-gasnet-timeouts

Try bumping qthreads+gasnet timeout for low core count machines again

[ok'd by @gbtitus]

There are still some timeouts for cyclic and linux32. Not happy with this 
solution, but it's the best we have right now.
Skip the two tests in test/arrays/deitz/parallelism/stream/ for --baseline

These tests are to ensure that our default settings (--fast-follower enabled)
utilize fast followers and create the right number of tasks for parallel work.
Since both are intended and --baseline turns off --fast-followers, it doesn't
make sense to run these tests under --baseline.
Merge pull request #741 from lydia-duncan/streamFastFollowersBaseline

Skip the two tests in test/arrays/deitz/parallelism/stream/ for --baseline
[reviewed by vass]

These tests are to ensure that our default settings (--fast-follower enabled)
utilize fast followers and create the right number of tasks for parallel work.
Since both are intended and --baseline turns off --fast-followers, it doesn't
make sense to run these tests under --baseline.  Ideally, we would want
to have the test throw --fast-followers when --baseline is thrown, but our test
system at the moment does not allow this and it doesn't seem like a big
deal to get this to run with --baseline, so skipping for
COMPOPTS <= --baseline seems like the right choice.  Throwing
--fast-followers for every setting struck me as defeating the point of
the test, so that option was ruled out.