LU-3117 build: zfs-0.6.1 kmod+dkms compatibility

LU-3117 build: zfs-0.6.1 kmod+dkms compatibility

With the release of zfs-0.6.1 the default install location of
the zfs kmod headers and objects has changed.  The kmod headers
which are common for a zfs version are now installed under
/usr/src/zfs-<version>/ path.  The objects, which are kernel
specific, are installed under /usr/src/zfs-<version>/<kernel>/.

This was done just prior to the official 0.6.1 release because
this scheme satisfies the packaging requirements of the major
distributions.  Making the change now means we shouldn't need
to change it again.

To accomidate this change the lustre-build-zfs.m4 has been
updated in the following ways:

* The new zfs header and object paths were added to the list
  of default search paths.  The DKMS build paths were also added
  to allow compilation against zfs-kmod or zfs-dkms packages.

* Support for building the spl and zfs code recursively as
  part of the Lustre build process was removed.

* The lustre-osd-zfs packages 'Requires' line was changed to
  require zfs-kmod.  Either the zfs-kmod or zfs-dkms packages
  can be used to satisfy this requirement.

* Fix incorrect usage of @ZFS_OBJ@ in osd-zfs/Makefile.in,
  the include directory us under @ZFS@ with the headers.
  These happens to be the same location before so it never
  caused issues.

* EXTRA_LIBZFS_INCLUDE renamed ZFS_LIBZFS_INCLUDE, this was
  done for consistency.

* Failing to build ldiskfs should not automatically disable
  all server support.  The zfs osd may still be buildable.

* General m4 cleanup and simplification of lustre-build-zfs.m4.

* Ensure new zfs/spl build correctly with lbuild.

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Change-Id: Ib686211c4f9ace39a41053ce8a20112d1121def9
Signed-off-by: Nathaniel Clark <nathaniel.l.clark@intel.com>
Reviewed-on: http://review.whamcloud.com/5960
Tested-by: Hudson
Tested-by: Maloo <whamcloud.maloo@gmail.com>
Reviewed-by: Alexey Shvetsov <alexxy@gentoo.org>
Reviewed-by: Andreas Dilger <andreas.dilger@intel.com>
Reviewed-by: Oleg Drokin <oleg.drokin@intel.com>