Make dynamic scheduler scaling more robust and configurable

[dipinhora]

Prior to this commit, dynamic scheduler scaling was not quite as
robust as we might like. When it came to waking sleeping threads,
the logic would send multiple wake signals in the hope that one
of them would work successfully and wake any sleeping thread that
might still be asleep. It was possible that even with sending
multiple signals, they could all be missed resulting in a thread
staying suspended when it should be awake.

This commit changes the logic to add a "check variable" that is
updated by threads after they wake up. This "check variable"
(active_scheduler_count_check) is a mirror of the current
active_scheduler_count and is used to confirm that a sleeping
thread has successfully woken up. This commit also changes the
logic to ensure that when threads are being woken up, they are
only sent a single signal (to minimize unnecessary work). If that
signal is missed, then scheduler thread 0 would notice that
active_scheduler_count != active_scheduler_count_check and send
another signal until the thread wakes up and updates the check
variable. This should ensure that it is not possible to have a
hanging thread due to missed signals. Overall, these changes
should make dynamic scheduler scaling more robust, including
allowing for scheduler thread 0 to also suspend. (Scheduler
thread 0 suspension is experimental because @slfritchie ran into
an issue related to programs hanging when using network IO and
suspending scheduler thread 0 a few months ago. This commit
should in theory resolve this due to the "check variable" but I
haven't had an opportunity to test and confirm whether it
actually does so or not.)

This commit also adds in a new command line option for dynamic
configutation of the threshold after which a thread is allowed to
suspend (and also separates it from the scheduler block threshold.
This new option is called --ponysuspendthreshold. This option
is needed because the current suspend threshold (about 1 ms) is
very aggresive and @slfritchie noted that scheduler threads
suspend and don't wake up even under high network load. This
option allows for the threshold to be increased (or decreased)
on a per application run time basis. Additionally, it likely
makes sense to change the default to be something more
"appropriate and balanced" based on some sort of fancy
heuristics/tests done with different values for the threshold.

[sylvanc]

This looks good. Dipin, are you comfortable with merging this, in terms of how well tested it is?

[dipinhora]

@sylvanc I am (based on my limited testing). But then again, I tend to be overconfident to a fault. It's probably better to have someone not-me do some sort of check to ensure I didn't break something without realizing it.

Also... rebased to fix merge conflict.