upcoming namecache work

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

    I am resuming the namecache work.  This is a prereq for several
    major DragonFly goals:

    userland vfs:	The namecache needs to be disentangled from the VFS
			code else there would be a billion messages flying
			between userland and kernelland.

    namespace locking:	The intention is for the namecache to be used for
			namespace locking operations rather then having to
			hold an exclusive lock on the directory vnode.

			This will deserialize directory operations such as
			rm -rf and allow any precursor I/O for multiple
			create, rename, and other directory operations to
			proceed in parallel.  The actual I/O operation on
			the directory will still need an exclusive lock,
			but we can potential do further optimizations

    vnode locking simplification:
			VFS operations (VOP_* calls) have extremely convoluted
			vnode locking requirements, primarily due to the fact
			that the kernel depends on directory vnode locking
			to prevent unexpected namespace changes from taking
			place.  VOP_RENAME() is especially bad.

			But if we do our namespace locking using the
			namecache, we can do away with exclusive directory
			locks during path lookups. 

			This also fixes the 'race to root' problem that NFS
			has (FreeBSD-5 fixed this by not locking the mount
			point directory), but this ALSO fixes filesystem
			chokepoints where a vnode lock can race up the
			directory chain and cause completely unrelated 
			processes to stall, which FreeBSD-5 does not fix.

    So, some big ticket items here which will be a nice feather in our cap.

					-Matt