Initial commit to try and get rid of qthread deadlock

There are a couple of tests that deadlock with qthreads now that the nemesis
scheduler is the default. They are tests where the main task is in a loop
waiting for a sync var to have a certain value and other tasks are being
created inside the while loop to increment the sync var. Some of the tasks
getting created never get to run because the main task never yields and thus
the main loop is waiting for tasks that it's not letting run to update a value.
To remedy this the plan is to do a qthread_yield every x unlocks for any given
sync var. This does a qthread_yield every 1024 iterations. I tried with 32 and
256 and they both seemed to yield too often through the non-scientific method
of putting some prints when we yield and seeing how often we yield for a few
test programs and also checking how long they take to finish into account.
Update to how often qthreads yields for sync var unlock

This moves the check to use the return value of qthreads_incr, which means we
get the previous value of lockers_out but we get rid of a race.

The previous code was something like if (lockers_out & 0xFF) then yield but you
want if ((lockers_out &0xFF) == 0) since the other way yields for all but the
one iteration. Finally, this bumps up the number of unlocks before yielding.
This is based on trials with test/domains/sungeun/assoc/stress.numthr.chpl .
No stack checks, and smaller stack for domains/sungeun/assoc/stress.numthr.chpl

For qthreads this test was running out of memory because there were too many
tasks existing at the same time. This was especially a problem with 8M stacks
so this lowers that to 128 and turns of guard pages to reduce memory usage and
because this test creates a lot of tasks. I believe this wasn't an issue for
fifo because there is a limited number of pthreads (and thus stacks) that can
exist, whereas qthreads imposes no such limit.
Don't yield for first unlock of sync var for qthreads sync var unlock

Previously yield for if ((lockers_out % 4096) == 0) meant we would yield on the
first unlock. This just changes it to if ((lockers_out % 4096) == 4095) so that
we still yield after the same number of iterations but the first yield is moved
back to the 4095 unlock instead of the first.
Lower how many iterations until we yield
Merge pull request #159 from ronawho/qthreads-syncvar-deadlock

Do a qthread_yield() after X number of unlocks on a sync variable

Note: This idea was ok'd and comes from greg and sung. This exact patch hasn't
been reviewed, but it passed full testing and I want to see the performance
results so that we can setup something for good testing over the weekend and
hopefully switch to qthreads as default after the weekend. After seeing the
performance and correctness results I'll update the patch and have it formally
reviewed.

After switching to the nemesis scheduler as the default scheduler for qthreads
we had 5 deadlocks essentially coming from 2 tests:
test/domains/sungeun/assoc/stress.chpl and test/users/shetag/fock/fock-1.chpl.

In these tests the main task is waiting for a sync var to have a certain value
while other tasks are incrementing that sync var. In this case some tasks that
are adding to the sync var are put on to run on the same worker as the main
task. The main task is never yielding and thus it keeps waiting for a sync var
to have a value that it is preventing from getting updated.

To remedy this, we now yield after 256 unlocks of any given sync var. The
specific number has come from some trial and error with the previous tests and
will probably change after some more trial and error and looking through
performance results.

This also lowers the stack size for a test that creates an enormous amount of
threads and turns off guard pages to avoid running out of memory.