hammer2 - refactor filesystem sync 2/N

hammer2 - refactor filesystem sync 2/N

* Flesh out the flush partitioning code, fixing a number of issues.

* Refactor hammer2_inode_lock() and add hammer2_inode_lock4() to
  interlock against flushes.  This is handled by blocking inode locks
  against SYNCQ, and reordering the inode to the front of the SYNCQ list
  in order to unblock as quickly as possible as the filesystem sync
  progresses.  The result should be relatively few frontend stalls
  during a filesystem sync.

* Disable resource caps for the moment, because synchronous
  operations to prevent resource limits from blowing out break
  the current inode_lock*() code and allow vnode deadlocks to
  occur.

* To avoid deadlocks, the filesystem sync currently must clear SYNCQ
  before locking the inode & vnode, and if it cannot lock a vnode it
  must continue on with the next inode and then restart.  Retried
  vnodes introduce a short delay to give the frontend time to work
  the blocking operation.

  This is necessary because the kernel locks vnodes before entering the
  H2 frontend, and we cannot safely unlock/relock them to work around
  this.  Nor do we necessarily even have full knowledge on which vnodes
  the current thread has locked.

* Does not yet guarantee complete filesystem consistency on-crash.