HAMMER VFS - Major retooling of the refcount mechanics, and fix a deadlock

HAMMER VFS - Major retooling of the refcount mechanics, and fix a deadlock

* Add an interlock to hammer_lock->refs which is independent of
  hammer_lock->lockval.

* Retool the refcount mechanics to integrate the interlock on 0->1 and
  1->0 transitions.

  In addition implement a check bit to deal with serialization races
  between threads which forces all threads to interlock.  This deals
  with the case where one thread bumps the refcount (lock->refs) but
  is unable to immediateliy acquire the interlock.  Other threads doing
  the same thing will race and lock->refs will be bumped far higher
  than 1.  The check bit is set on the 0->1 transition and enforces
  all threads to serialize until one (usually the first to acquire the
  lock) is able to dispose of the check condition.

  The transition interlocks are used to do I/O loading and validation
  on the 0->N transition and I/O unloading and invalidation on the 1->0
  transition.

* The new integrated mechanics also simplify hammer_io's handling of
  B_LOCKED slightly and properly interlocks changes in disposition for
  the related buffer cache buffer against refcount transitions.

* The new integrated refcount/interlock is also more optimal as the
  combined operation can be done in a single atomic_cmpset_int() call,
  and fully MPSAFE.  Even though other major portions of HAMMER are not
  yet MPSAFE getting this particular bit dealt with will ease MP work
  later on.

* Retool the volume, buffer, and node referencing code to use the new
  mechanics.  This fixes a deadlock.  These routines were previously
  acquiring an exclusive lock instead of an interlock.  The exclusive
  lock could combine with shared locks held by the same thread to create
  a deadlock situation against other threads.

  Use of the interlock fixes this particular deadlock.

Reported-by: Francois Tigeot <ftigeot@wolfpond.org> (deadlock report)