hammer2 - Implement nsymlink, readlink, remove, and rmdir

hammer2 - Implement nsymlink, readlink, remove, and rmdir

* Implement nsymlink and readlink.  Currently requires VMIO because core
  file r/w procedures are used to read and write the symlink target.
  The symlink target will use inode-embedded data for targets with a
  string length <= 512 bytes.

* Move a number of functions embedded in VOPs to their own separate
  procedures so they can be called from multiple VOPs.  So far: read,
  write, and remove.  Truncate and extend already had their own
  helper procedures.

* Implement rm and rmdir.  Currently does not optimize the presence of a
  cached vnode (to get to the ip->chain), but the directory lookup is
  cheap so it might not matter.

  Implement two interesting optmiizations.

  First, free block handling is not done in the active path.  Since we
  never know what snapshots might be pointing deep into our directory
  hierarchy there's no point.  This means that a removal only needs to
  modify the parent chain element pointing to the item.  The item itself
  DOES NOT NEED TO BE MODIFIED IN ANY WAY, even if it is representitive
  of a deep hierarchy (such as if it is a large file).

  Second, recursive removals ala 'rm -rf' can proactive CLEAR the modified
  bit on directory elements being removed that were previously marked
  modified due to removals made from within those elements.

  Together this can reduce the amount of write I/O required to remove a
  directory hierarchy OF ANY SIZE, even terrabytes, to near zero.

* Hardlinks not yet handled but for the hardlink case the directory entry
  itself will be a dummy and thus can be removed without modification.  The
  related 'real' inode, when we implement hardlinks, will be in some
  parent directory and it will be marked modified.  However, if a rm -rf is
  able to traverse upward through that parent then even the real hardlink
  inode will be re-marked as unmodified and virtually no write I/O will
  result.