Giantless VFS.

I have a patch that I would like people to test and review.  It's
available here:

http://www.chesapeake.net/~jroberson/smpffs.diff

The short description:
This patch removes Giant from the read(), write(), and fstat() syscalls,
as well as page faults, and bufdone (io interrupts) when using FFS.  It
adds a considerable amount of locking to FFS and softupdates.  You may
also use non ffs filesystems concurrently, but they will be protected by
Giant.  If you are using quotas you should not yet run this patch.  I have
done some buildworlds, but any heavy filesystem activity would be
appreciated.

Long description:
There is now a per mount-point mutex in struct ufsmount that covers ffs's
struct fs related allocation routines.  The rest of the filesystem was
already covered by the buffer locks on cgs, indirs, etc, as well as a few
mutexes that were already in place.  I made great attempts to minimize the
number of lock operations for the common cases which resulted in a couple
of functions which may be entered with the UFS lock held, but return
without it held.  Where this is not already done, it will be documented in
comments.

The softupdate lk lock has been turned into a mutex, and it now protects
all global worklists, inode and page dep hash buckets, etc.
interlocked_sleep() is gone now that BUF_LOCK() and msleep() take
interlock arguments.  getdirtybuf() has been slightly changed to solve
some sleep related races that I disucssed with Kirk.  For now there is a
single softupdates mutex, but eventually it will be made per-mountpoint
and potentially merged with the ufsmount lock.

On the infrastructure side, the buffer cache was locked some time ago, and
now the vm is safe to run without Giant, so there are simply a lot of
removed GIANT_REQUIRED lines.  I added some locking to vn_start_write()
and friends, and made some changes for LORs there.  There is a pair of new
macros called VFS_(UN)LOCK_GIANT(mp) which inspects a new flag on the
mount-point to determine if we have to acquire giant.  This is done very
early in the syscall path before we call any VOPs.  The mountpoints should
be safe to inspect as we always own a reference to the vnode in the cases
that I have unwound for now.

Cheers,
Jeff