While working on the following RFE:

    JDK-8256302 releasing oopStorage when deflating allows for faster deleting

I ran into some minor issues with monitor deflation logging and the
deflate_idle_monitors() calls.

- The logging call near the end of ObjectSynchronizer::deflate_idle_monitors()
  that describes the work done in MMM.NNNNNNN seconds should include
  unlinked_count and deleted_count in addition to deflated_count.

- The deflate_idle_monitors() call in
  ObjectSynchronizer::do_final_audit_and_print_stats() should
  continue when 1 or more monitors is deflated. By stopping after
  the first count < MonitorDeflationMax is encountered, it is possible
  to miss other deflation attempts where count < MonitorDeflationMax
  is encountered. This can happen during the final audit when the
  MonitorDeflationThread has paused for the final safepoint after
  deflating some number of monitors, but the pause happens before
  the deflated monitors are unlinked. The VMThread will be able to
  unlink these monitors if it does another deflate_idle_monitors() call
  after the first count < MonitorDeflationMax is encountered.
 
- The deflate_idle_monitors() call in VM_ThreadDump::doit()
  should continue when 1 or more monitors is deflated. This
  situation is similar to do_final_audit_and_print_stats() where
  the MonitorDeflationThread could be blocked for a safepoint
  and the VMThread could do the unlinking that was deferred
  for the safepoint pause.