Use fsal_filesystem in FSAL_VFS to implement multiple filesystems

This is a major change...

The VFS handle has been reformatted. Now Linux core VFS, FREEBSD, and
XFS each have their own handle format. The FREEBSD and XFS handles
already had an fsid in them. The format of the core Linux handle is:

/* Visual handle format
 *
 * 1 byte		handle_len (doesn't go on wire)
 * 1 byte		flags
 *				00xxxxxx fsid_type
 *				01000000 handle_type fits in one byte
 *				10000000 handle_type fits in two bytes
 *				11000000 handle_type fits in four bytes
 */
 /*
 * 0, 8, or 16 bytes	fsid type
 * 1,2 or 4 bytes 	handle type
 * 12 to 40 bytes	opaque kernel handle
 *
 * NOTE: if handle type doesn't fit in 2 bytes or less, 40 byte handles
 *	 (BTRFS and GPFS are known file systems that use 40 bytes) are
 *	 incompatible with 16 byte uuid form fsids.
 *	 If VMware clients are concerned, the limit is 8 bytes less...
 */

FREEBSD and XFS file systems will use the fsid from the handle as the
fsid, and thus will be re-indexed.

The FSAL configuration for an export may specify the filesystem type.
This really only applies to core Linux filesystems. The types are:

None
One64 (one uint64_t)
Two64 (two uint64_t)
uuid  (synonym for Two64)
Two32 (two uint32_t)
Dev (two uint32_t using the device major.minor)
Device (synonym for Dev)

An FSAL lookup that crosses a filesystem boundary will be properly
handled, with fsid changing and everything. This allows sub-mounted
fileysystems to work properly for both NFS v3 (at least with the Linux
client) and NFS v4 (with any client that crosses filesystem boundaries).

The fsid for the filesystem is used for fsid in getattrs.

Signed-off-by: Frank S. Filz <ffilzlnx@mindspring.com>
Extract xfs out into FSAL_XFS

FSAL_XFS shares most of it's code with FSAL_VFS, but is now an
independent FSAL. This solves some issues, and get's rid of the
need to specify the handle library path.

Signed-off-by: Frank S. Filz <ffilzlnx@mindspring.com>

Conflicts:
	src/FSAL/FSAL_VFS/export.c
	src/FSAL/FSAL_VFS/handle.c
Simplify vfs_stat_by_handle

Signed-off-by: Frank S. Filz <ffilzlnx@mindspring.com>
Use open_dir_by_path_walk in FSAL_GPFS gpfs_lookup_path

Signed-off-by: Frank S. Filz <ffilzlnx@mindspring.com>
Use open_dir_by_path_walk in FSAL_LISTRE lustre_lookup_path

Signed-off-by: Frank S. Filz <ffilzlnx@mindspring.com>
Don't allow ".." path elements in FSAL_PROXY pxy_lookup_path

symlink elements should result in errors, but we need to be explicit
about preventing use of ".." path elements in pxy_lookup_path.

Signed-off-by: Frank S. Filz <ffilzlnx@mindspring.com>
Improve handling of crossing FSAL boundaries in POSIX namespace

Take the following filesystems:

/export/xfs
/export/xfs/some/path/ext4

Assume /export/xfs is exported FSAL_XFS and /export/xfs/some/path/ext4
is exported FSAL_VFS. The directory /export/xfs/some/path/ext4 must
have two cache inodes, one that looks like an FSAL_XFS inode, and one
that looks like an FSAL_VFS inode. These are required to make the
export junction work.

Of course xfs can not do name_to_handle_at on
/export/xfs/some/path/ext4. When we get an error back from that
call, we just invent a handle (basically just the fsid wich will
not conflict with any FSAL_VFS or FSAL_XFS handle.

Signed-off-by: Frank S. Filz <ffilzlnx@mindspring.com>