Bump timeout for gasnet+qthreads testing on low core count machines

On low core count machines like the linux32 box, lnx-diten, and lnx-vass we
still have some timeouts with gasnet+qthreads even when built with
oversubscription on and affinity off. The reason we see it on these machines
but not for regular gasnet testing is just because these machines have a lower
core count.

This increase in timeout does NOT reflect true performance issues with
qthreads, but merely the fact that qthreads wasn't designed to run in an
oversubscribed manner. Qthreads expects that it owns the whole machine. With
oversubscription on, amongst other things, busy loops turn into loops with
sched_yield in them. While this yields the processor, the qthread is not
yielded and so there are still situations where it takes much longer to get
work done because qtheads doesn't own the whole machine, but fundamentally
assumes it does.

Increasing the timeout is a stop-gap to quiet nightly testing until I figure
out a better solution, or we start doing gasnet testing on real hardware.

I tried a few things to get rid of timeouts with little success including
modifications to qthreads source, and limiting CHPL_RT_NUM_THREADS_PER_LOCALE
to numCores/numLocales. Limiting the number of threads doesn't help on low core
count machines because you get 1 thread per locale, which is equally as slow as
the contention in most cases.

I can look for a better solution as a background test, but this will quiet
testing in the meantime.
Merge pull request #729 from ronawho/qthreads-gasnet-timeouts

Bump timeout for gasnet+qthreads testing

[ok'd by @gbtitus]

On low core count machines like the linux32 box, lnx-diten, and lnx-vass we
still have some timeouts with gasnet+qthreads even when built with
oversubscription on and affinity off. The reason we see it on these machines
but not for regular gasnet testing is just because these machines have a lower
core count.

This increase in timeout does NOT reflect true performance issues with
qthreads, but merely the fact that qthreads wasn't designed to run in an
oversubscribed manner. Qthreads expects that it owns the whole machine. With
oversubscription on, amongst other things, busy loops turn into loops with
sched_yield in them. While this yields the processor, the qthread is not
yielded and so there are still situations where it takes much longer to get
work done because qtheads doesn't own the whole machine, but fundamentally
assumes it does.

Increasing the timeout is a stop-gap to quiet nightly testing until I figure
out a better solution, or we start doing gasnet testing on real hardware.

I tried a few things to get rid of timeouts with little success including
modifications to qthreads source, and limiting CHPL_RT_NUM_THREADS_PER_LOCALE
to numCores/numLocales. Limiting the number of threads doesn't help on low core
count machines because you get 1 thread per locale, which is equally as slow as
the contention in most cases.

I can look for a better solution as a background test, but this will quiet
testing in the meantime.