Put a usleep(1) in chpl_thread_yield for cygwin

We discovered that tests such as parallel/taskPar/sungeun/taskCount.chpl took
an exceptionally long time to complete on cygwin. After further investigation
it seems sched_yield isn't doing what we expect on cygwin.

According to the man page:

"sched_yield() causes the calling thread to relinquish the CPU. The thread is
moved to the end of the queue for its static priority and a new thread gets to
run."

However for cygwin it seems that a thread can be immediately rescheduled even
if there are others waiting to run. To get around this, this places a usleep(1)
after the sched_yield.

We believe this will force the thread to give up it's time slice and allow
another thread to actually run. This works for taskCount.chpl which completes
in .04 seconds with this as opposed to 300 seconds w/o it.

I tried using nanosleep as well to minimize time spent sleeping but it has no
real affect. I believe the rest of the remaining time slice is being given up
and the time slice is on the order of milliseconds so sleeping for nanoseconds
would only be helpful if the thread were extremely near the end of it's time
slice.

There are other sched_yields that are called and those may need to have similar
sleeps after them, but this is the first attempt to see what happens with
nightly testing.

ZwYieldExecution is the function that sched_yield maps down to and it
guarantees no fairness.
Merge pull request #696 from ronawho/cygwin-sched_yield

Put a usleep(1) in chpl_thread_yield for cygwin

[idea ok'd by brad and lydia on chat]

We discovered that tests such as parallel/taskPar/sungeun/taskCount.chpl took
an exceptionally long time to complete on cygwin. After further investigation
it seems sched_yield isn't doing what we expect on cygwin.

According to the man page:

"sched_yield() causes the calling thread to relinquish the CPU. The thread is
moved to the end of the queue for its static priority and a new thread gets to
run."

However for cygwin it seems that a thread can be immediately rescheduled even
if there are others waiting to run. To get around this, this places a usleep(1)
after the sched_yield.

We believe this will force the thread to give up it's time slice and allow
another thread to actually run. This works for taskCount.chpl which completes
in .04 seconds with this as opposed to 300 seconds w/o it.

I tried using nanosleep as well to minimize time spent sleeping but it has no
real affect. I believe the rest of the remaining time slice is being given up
and the time slice is on the order of milliseconds so sleeping for nanoseconds
would only be helpful if the thread were extremely near the end of it's time
slice.

There are other sched_yields that are called and those may need to have similar
sleeps after them, but this is the first attempt to see what happens with
nightly testing.

ZwYieldExecution is the function that sched_yield maps down to and it
guarantees no fairness.