Embed libcork

Instead of grabbing things from it piecemeal, let's just embed a copy of
libcork.
Locked task queues

Each execution context (of which there is currently...one) has a local
list of tasks that are ready to be executed.  Eventually we're going to
implement work stealing, where execution contexts can grab tasks from
each other.  Once we have multiple threads trying to access the same
data structures, we'll need some kind of synchronization.  Let's start
with a basic spinlock.  Once we have something that works correctly, we
can try experimenting with other approaches.
Thread-safe task groups

The task group functions are now (mostly) thread-safe.  (The main thing
that is still not thread-safe is marking that a group should be executed
after some other group has finished; this is thread-safe for the
“before” group, but not for the “after” group.)

In addition, the API has been cleaned up a bit; in particular, there are
now four explicit states that a task can be in, as described in the
flt_task(3) man page.
Type-specific flt_local accessors

Most of the flt_local functions now take in the type of the instances
being managed.  This is repetitive, but it means we have remove one
layer of pointer indirection in our implementation.  Since flt_locals
are used in a quite a few hot code paths, this actually has a noticeable
impact on the running time.

This means that instead of `new` and `free` callbacks, you provide
`init` and `done` callbacks, since the flt_local manager allocates a
single array of instances.  To eliminate false sharing, we pad each
instance to the size of a cache line (which we're currently hard-coding
as 64 bytes.)
Track number of task executions in each context

Each execution context now maintains a count of the number of task
executions in its ready queue.  (This includes each execution of a bulk
task.)  We'll use this count in the work-stealing scheduler to determine
how much work to steal at one time.
Run one example at a time

The fleet-examples test program runs several different example
computations in several different fleet configurations.  This patch
updates it so that you can choose to run only one example, in one
configuration.  The usage is either:

    $ fleet-examples

to run everything, or

    $ fleet-examples [config] [example] [options]

to run a single example.  Each example takes in additional options to
choose how large of an input to run against, for instance.
Track wall-clock time of examples

We now output the wall-clock time as well as the CPU time when running
our performance examples.  That lets us see how many CPU cores we're
able to pin.
Aligned flt_local instances

Each instance in an `flt_local` manager should be in a separate cache
line in memory.  This eliminates “false sharing”: if two instances are
in the same cache line, then the threads that own those instances will
“step on each other”, since they'll be bogged down sending cache updates
to each other.  By making sure each instance is in a separate cache
line, each thread is able to execute its code unimpeded.

We were already adding padding between each instance in the underlying
array, in an effort to push each successive element into a new cache
line.  However, we also need to align the array itself.  If we don't do
that, then each element, while spaced far enough apart, will fall on a
cache line boundary, guaranteeing that we'll have false sharing.
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.
Merge branch 'feature/multi-threaded' into develop

* feature/multi-threaded:
  Work stealer
  Aligned flt_local instances
  Track wall-clock time of examples
  Run one example at a time
  Track number of task executions in each context
  Type-specific flt_local accessors
  Thread-safe task groups
  Locked task queues
  Embed libcork