…cks.

The built-in clocks should have implementations of `run` and `enqueue`,
to allow derived clocks to call those implementations.

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.

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.

Add some documentation comments to the Dispatch and CF executors,
and update the comments for the allocation and private data APIs.

Rather than just looking at top level in the module, start by searching
the type marked as `@main`.  This means that a library that provides a
protocol or superclass that the `@main` type can conform to can specify
an executor in a reasonable manner.

Also add `final` to the `CooperativeExecutor` declaration.

We've removed this code, so the test was failing.

…run.

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.

There was still some canonicalization in one of the tests, plus we needed
to update the ABI tests.

This fixes some WASM tests.

Some mentions of `ExecutorJob` were not guarded by the required
`SWIFT_STDLIB_TASK_TO_THREAD_MODEL_CONCURRENCY` condition.