hammer2 - stabilization, sequencing

hammer2 - stabilization, sequencing

* Change the way XOPs are dispatched.  Instead of dispatching a XOP
  to specific service threads in the xgrp we now queue the XOP to a
  per-cluster-node xopq and allow the service threads to compete for
  work.

* Implement XOP dependency tracking.  Cluster nodes can complete execution
  of a XOP in any order and the frontend may complete early on-quorum while
  the XOP is still executing on other cluster nodes.  In this situation
  the inode lock may be released or cycled and another, dependent XOP may
  be issued, potentially executing out of order on the cluster nodes that
  have not yet finished (or possibly even started) the previous XOP.

  With the new queueing mechanism we also implement dependency tracking
  using the xop->ip1, ip2, and ip3 fields.  Dependent XOPs on (slow) cluster
  nodes will be held-back and ordering of dependent XOPS will be enforced.

  This fixes one of several cluster-related issues that will need to be
  addressed in order to free the frontend of slow backend cluster nodes.

* The strategy XOP now uses a per-XOP lock instead of an xgrp lock
  (xgrp is no longer used in the xop structure and XOPs are now
  distributed to potentially different xgrps for each cluster node).

* Normalize some structural field names.

* bulkfree now takes a snapshot of vchain, using a separate (temporary)
  chain structure which isolates the entire topology scan from the
  live filesystem.

  This required minor adjustments to base/count handling for
  HAMMER2_BREF_TYPE_VOLUME and HAMMER2_BREF_TYPE_FREEMAP.

* Debugging adjustments.