* 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.