usr.sbin/makefs: Add HAMMER2 support

usr.sbin/makefs: Add HAMMER2 support

This commit adds HAMMER2 image creation support for makefs(8).
It runs newfs_hammer2(8) and then sys/vfs/hammer2 logic in userspace
to create HAMMER2 image from a given directory.

This commit splits newfs_hammer2(8) into newfs and mkfs part simlarly
to newfs_msdos(8), so that makefs(8) can use newfs functionality.
The entire sys/vfs/hammer2 (with exception of unneeded
hammer2_{bulkfree,ccms,iocom,ioctl,msgops,synchro}.[hc] and reusable
hammer2_disk.h) is copied to usr.sbin/makefs with below modification.
It intends to have minimum amount of diff against sys/vfs/hammer2.

* Header includes are modified so that it compiles in userspace.
* VFS and other kernel functions are usually implemented as simple
 stub functions in hammer2_compat.h and hammer2_buf.c, but some are
 commented out.
* Kernel functions such as kprintf, kmalloc, kprintf, kstrdup, etc
 are implemented using corresponding libc functions.
* Lock primitives are basically NOP, and they (should) never block
 as makefs(8) is a single thread program.
* struct vnode and struct buf (the ones defined locally in makefs(8),
 not sys/sys/*) have new struct members only used by HAMMER2 to
 emulate VFS behavior required by HAMMER2.
* Since makefs(8) is write-only, VOP_{NRESOLVE,NCREATE,NMKDIR,NLINK,
 NSYMLINK,WRITE,STRATEGY} are implemented, but other VOPs just
 return EOPNOTSUPP.
* VOP_{INACTIVE,RECLAIM} may be implemented and used in future to
 better emulate VFS behavior to address current limitation.
* VOP_WRITE is modified to directly call VOP_STRATEGY function.
* The XOP kernel thread is modified to act as a regular function
 called from VOPs, along with simplified admin code.

It currently has following limitations.

* multi-volumes is unsupported, simply due to makefs(8) only taking 1
 image file path.
* Not necessarily a limitation, but it only supports populating 1 PFS,
 which is "DATA" by default. Other PFSes if any won't have anything
 under the root PFS inode.
* makefs(8) process gets killed by OOM for a directory with *extremely*
 large number of files, depending on available memory. This is due to
 the way it currently tries to flush all chains in a single VFS_SYNC.
 Supporting multiple VFS_SYNC calls by checking available memory along
 the way gives chance to free unused vnodes/inodes and chains. This
 may be implemented in future. This limitation is specific to HAMMER2,
 as all other makefs(8) filesystems are not CoW, meaning they allow
 in-place write based objects creation from a top directory to bottom
 whereas HAMMER2 flushes chains in bottom-up direction.