kernel - Fix shared lock bug in kern_mutex.c

kernel - Fix shared lock bug in kern_mutex.c

* When the last exclusive lock is unlocked or when downgrading an exclusive
  lock to a shared lock, pending shared links must be processed.  The
  last 'lock count' is transfered to the first link, thus preventing the
  lock from getting ripped out from under the transfer code.

* However, when multiple shared links are pending, it is possible for the
  first recipient link to wakeup and release its lock before the unlock/drop
  code is able to finish its scan, which places the lock in an unexpected
  state.  The lock count was only being incremented within the link scan
  loop, once at a time.

* Fix the problem by applying a lock count representing ALL pending
  shared lock links after the first one before processing the first link.
  This ensures that the lock remains in a shared-lock state while the loop
  is running.

* This fixes a race that can occur in HAMMER2.