Work stealer

We now finally have a work-stealing scheduler.  Each fleet will, by
default, spin up one thread per CPU core on the machine, and create a
separate execution context for each thread.  You can override this using
the `flt_fleet_set_context_count` function.  The initial task is
arbitrarily assigned to one of the contexts.  If a context ever runs out
of tasks to execute, it will try to steal tasks from one of the other
contexts.  All of the necessary thread synchronization is handled by the
scheduler.

I've also added some optional debugging and timing messages, which are
only compiled in if you set the `FLT_DEBUG` and `FLT_MEASURE_TIMING`
macros, respectively.

With the current implementation, we don't see any speedup with the
`sequential_return` and `sequential_run` tests, which makes sense, since
they don't have any concurrency to exploit.  Even better, the overhead
of having the extra contexts (which can't ever find anything to do) is
minimal.

The `concurrent_unbatched` example sees perfectly linear speedups, since
we create a single bulk task for all of the tasks that we want to
execute.  This means that amount of time spent stealing is minimized,
since each context can immediately steal a chunk of the bulk task and
then churn away executing.

The `concurrent_batched` example is a different story.  With small batch
sizes, we can't really exploit any parallelism, because there's never a
large enough pool of pending tasks to spread between the different
contexts.  As we get to larger batch sizes, we can spread things out
better, but because we're creating and scheduling so many more task
objects, there's some churn and overhead as each context steals some of
the remaining work from each other.  But still, not bad to start.