cells: add per-cell CPU usage monitoring

This patch adds support for monitoring what percentage of time is spend in each of the
cells in a domain.  It works by keeping track of both which cell a thread is associated
with and how "fast" a thread is accumulating CPU time.  (Each cell has its own
ThreadGroup, which allows a Thread to be associated with a cell).  By summing over all
threads in a cell, the CPU load for a cell may be calculated.  The calculations are done
periodically and yield two values per-cell: total accumulated time and CPU used since the
last query.

The motivation is that, should a domain be unusually active (e.g., during a quiescent
period or if unusual CPU pattern is observed in Ganglia) then this patch allows discovery
of which cell is causing this activity.  This is important as an instance might be
started without the necessary command-line options to allow CPU profiling and restarting
the domain might not lead to the same conditions.

The monitoring may be enabled or disabled.  When disabled, there is no overhead from this
patch.  When enabled there is some (indirectly) overhead in creating a thread since
discovering the new thread's Thread object is expensive.  The result is cached, so there
is little additional overhead if two threads are created.  There is also overhead from
querying how much CPU each thread has used.  Empirical evidence suggests the default
value (querying every 2 seconds) adds only a small CPU burden (1%--2%); however, this was
on an otherwise quiet system.  This feature is disabled by default to be safe.

The differential output (CPU consumed by a cell since the last update) is shown by the
"cpu ls" command.  This lists all known cells along with the percentage of user, system
and combined CPU usage over the past quantum.  The relative CPU usage is shown by a short
(two character) bar to the right of that cell's usage.

The patch works because each cell has its own ThreadGroup.  Per-service CPU accounting
may be possible if each service where also to have its own ThreadGroup.

Although this patch provides information about which cell is problematic, it may not
provide sufficient information to diagnose the problem and further information may be
needed (e.g., listing the top ten CPU-consuming threads).