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.