We were terminating after the first set of jobs; if one of them scheduled
another job, and there were no timers running, we would terminate,
which was wrong.
If a job enqueues another job on the executor, we might never leave
the inner `while` loop in the `run()` method. Fix this by taking
the contents of the run queue and only running those jobs in the
queue at the time we enter the inner loop.
I don't think we actually need this. If you have a non-canonical
(i.e. derived) clock, you can just implement `enqueue` and/or `run`
and call those methods on the clock you're wrapping.
We no longer attempt to convert timestamps from the passed-in `Clock`
in order to allow any clock to work with any executor. Instead,
executors that do not recognise a clock should call the `enqueue`
function on that `Clock`, which lets the `Clock` itself decide how
to proceed.
Additionally, rename `SchedulableExecutor` to `SchedulingExecutor`.
If you use SwiftStdlibCurrentOS availability, you will be able to
use new types and functions from within the implementation. This
works by, when appropriate, building with the CurrentOS availability
set to the current deployment target.
rdar://150944675
`CooperativeExecutor` should fall back to heap allocations if the task
allocator isn't available when it's enqueuing delayed jobs.
Also, remove the reference to `DispatchGlobalExecutor` from the
custom executor test.
rdar://141348916
