Customizable task migration and private deques

This patch implements the “receiver-initiated” stealing algorithm from
[1], which allows us to use private task deques within each execution
context.  This eliminates any slow synchronization primitives in the
fast path of each context's execution thread — each context is the only
entity that can push or pop tasks from any deques that it owns.  Tasks
steal from each other by communicating through some simple
message-passing channels:  First, the stealer task notifies the target
task that it wants to steal.  When the target notices this, it stops
executing tasks long enough to “migrate” some it tasks from its `ready`
deque into a special `migrating` deque.  Once this is done, it transfers
ownership of this `migrating` deque to the stealing context.  This
allows the stealing context to use this as its new `ready` deque, since
the ownership transfer allows it to pop tasks off of it.

This patch also implements a new `migrate` callback for tasks, which
allows a task to update its `ud` parameter when its moved from one
context to another.  (This can only happen before the task actually
executes; one the task starts executing its locked to a single context.)
This lets us implement a new `flt_local` API.  Before, a `struct
flt_local` was a single global pointer referring to a single
context-local data value.  You would use `flt_local_get` to retrieve the
context-specific pointer for that value.  We made this pretty fast, but
with the new API, you don't need the separate global pointer anymore.
Instead, you give the task the context-specific pointer for the context
that it's initially scheduled with.  If the task is ever migrated, then
only at that point do we have to update the pointer to point to a new
context value.  We optimize for the case that the new task will execute
in the same context as the task that created it.

[1] UA Acar, A Charguéraud, M Rainey.  “Scheduling parallel programs by
    work stealing with private deques.”  PPoPP 2013, ACM.
Remove task count from task deques

We can shave some cycles by not maintaining the per-context task count
each time we schedule and run a task.  That means that we have to walk
through more of the deque each time one context steals from another, but
we're not optimizing for the migration case, so that shouldn't be a
problem.
steps