hammer2 - flush sequencing part 4 - stabilization and cleanup, flush sep

hammer2 - flush sequencing part 4 - stabilization and cleanup, flush sep

* Fix bugs in the handling of DIRECTDATA.  The data for small
  files <= 512 bytes is stored in the inode itself using the
  area that would otherwise contain the indirect block table.

  Cleanup the flag handling for this data, ensure synchronous bwrite()s
  for this data area (the strategy code for direct-data reads and writes
  doesn't actually do any I/O), and ensure proper read-before-write
  operation.

* Adjust hammer2_inode_create() and hammer2_chain_modify_ip() to take/return
  (*chainp).

* Change the inode locking APIs to return the locked chain (unlocking APIs
  take the locked chain as an argument).  This allows the chain to be
  manipulated by the code inbetween, including replacing it with other
  chains, instead of the mess we had before where ip->chain had an implied
  lock associated with it.

  With this change, replacing ip->chain is just a matter of adjusting
  ref counts and not also having to worry about locks.

* Modify the inode chain proactively instead of indirectly.

* Set HAMMER2_INODE_MODIFIED proactively instead of indirectly.  This flag
  is now only used to filter vfs_sync scans.

* Start working on flush transitions.  hammer2_modify_chain() and friends
  will now delete/duplicate an underlying chain that is already in the
  MODIFIED state (returning the new chain) for the case where the previous
  modifications are associated with a flush-in-progress and the current
  modifications are outside of that flush.

* Add hammer2_chain_delete_duplicate(), a function which combines the
  DELETE and duplication operation in one atomic op.  Otherwise a lookup
  or find can catch such operations in the middle and improperly believe
  that the element is fully deleted when it isn't.

* Fix chain refs in a few places.