Make the use of statfs()/statvfs() be more robust.

As noted by Paul Hargrove, the #if's surrounding the use of statfs()
and statvfs() in opal/util/path.c have apparently gotten stale (e.g.,
modern flavors of *BSD OSs no longer define __BSD).  Changes:

 * Add statfs and statvfs to the AC_CHECK_FUNCS in configure.ac
 * Add a sanity check to ensure that we have at least one of statfs()
   or statvfs().  Add a similar sanity check in opal/util/path.c, just
   as defensive programming.
 * Use AC_CHECK_MEMBERS in configure.ac to check for specific struct
   statfs/struct statvfs members that we use in opal/util/path.c
 * In path.c, add some #includes as listed on the OS man page for
   statfs(2) (OS X 10.8.5/Mountain Lion)
 * The previous code used statvfs() on Solaris and statfs() everywhere
   else.  Attempting to replicate this with behavior-based configure
   testing led to fairly complicted if/else logic, so the new code
   uses whichever of the two are available (i.e., it might actually
   use both -- OS X 10.8.5 and RHEL 6.5 have both statfs() and
   statvfs()).  The rationale here is that we don't really care which
   of the two functions report the answer; we'll take the answer
   regardless of where it comes from.  For example, if one function
   returns a failure and the other does not, we'll use the results
   from the successful function and ignore the failed one.

This new code seems to work on OS X and Linux.  We'll have to see what
happens with MTT and future Paul Hargrove testing...

cmr=v1.7.4:reviewer=ompi-rm1.7:subject=Make statfs/statvfs more robust