Lower number of unlocks before doing a qthread yield

I had previously increased the number because I thought it was the source of a
performance regression. However, it turned out to be a different commit around
the same time. The previous number left some timeouts for tests that were
previously deadlocking. This lowers the number of unlocks to 1024 from 4096,
but not back down to the original low of 256 because there were some slight
performance regressions from that.

Note that this is still not necessarily the "final" number and that a
qthread_yield will still be added to the spinlock loop in the sync var lock but
I want to get performance results with this value first.
Merge pull request #180 from ronawho/qthreads-syncvar-deadlock

Lower number of unlocks before doing a qthread yield

[trivial/continuation of previous qthreads experiments, not reviewed]

I had previously increased the number because I thought it was the source of a
performance regression. However, it turned out to be a different commit around
the same time. The previous number left some timeouts for tests that were
previously deadlocking. This lowers the number of unlocks to 1024 from 4096,
but not back down to the original low of 256 because there were some slight
performance regressions from that.

Note that this is still not necessarily the "final" number and that a
qthread_yield will still be added to the spinlock loop in the sync var lock but
I want to get performance results with this value first.
Merged chapel-lang/master