[util] Import ThreadPool and Thread from KUDU

[chaoyli]

Thread pool design point:
All tasks submitted directly to the thread pool enter a FIFO queue and are
dispatched to a worker thread when one becomes free. Tasks may also be
submitted via ThreadPoolTokens. The token wait() and shutdown() functions
can then be used to block on logical groups of tasks.
A token operates in one of two ExecutionModes, determined at token
construction time:

1. SERIAL: submitted tasks are run one at a time.
2. CONCURRENT: submitted tasks may be run in parallel.
   This isn't unlike submitted without a token, but the logical grouping that tokens
   impart can be useful when a pool is shared by many contexts (e.g. to
   safely shut down one context, to derive context-specific metrics, etc.).
   Tasks submitted without a token or via ExecutionMode::CONCURRENT tokens are
   processed in FIFO order. On the other hand, ExecutionMode::SERIAL tokens are
   processed in a round-robin fashion, one task at a time. This prevents them
   from starving one another. However, tokenless (and CONCURRENT token-based)
   tasks can starve SERIAL token-based tasks.

Thread design point:

1. It is a thin wrapper around pthread that can register itself with the singleton ThreadMgr
   (a private class implemented in thread.cpp entirely, which tracks all live threads so
   that they may be monitored via the debug webpages). This class has a limited subset of
   boost::thread's API. Construction is almost the same, but clients must supply a
   category and a name for each thread so that they can be identified in the debug web
   UI. Otherwise, join() is the only supported method from boost::thread.
2. Each Thread object knows its operating system thread ID (TID), which can be used to
   attach debuggers to specific threads, to retrieve resource-usage statistics from the
   operating system, and to assign threads to resource control groups.
3. Threads are shared objects, but in a degenerate way. They may only have
   up to two referents: the caller that created the thread (parent), and
   the thread itself (child). Moreover, the only two methods to mutate state
   (join() and the destructor) are constrained: the child may not join() on
   itself, and the destructor is only run when there's one referent left.
   These constraints allow us to access thread internals without any locks.

[lingbin]

LGTM