Do not panic if somebody makes a call on dying filesystem

Instead return EIO error (bad file descriptor). Such error might happen
in case of short living filesystem - right after a filesystem mounted fseventsd
process sends a ton of requests. If user unmounts this filesystem at this moment
then we have a crash. Instead return an error saying that file is invalid.

Conflicts:
	fuse_vnops.c
On deadfs return ENXIO error instead of EBADF and EIO

There are few places were EBADF/EIO is used and there are places where ENXIO
is used. Unify and use ENXIO everywhere as it matches this situation better.

NFS and other filesystems in XNU returns this error on a filesystem without
alive backend.

Conflicts:
	fuse_vnops.c
If operation mmap is not supported, return ENODEV

Unsupported vnode operations return ENODEV by default. Returning EPERM just
beause ubc_map() ignores any other error code does not seem right especially
since EPERM does not prevent the mapping, either.

The ubc_map documentation states:

   It [ubc_map()] is primarily used by:

    o mmap(), when mapping a file
    o The deprecated map_fd() interface, when mapping a file
    o When mapping a shared file (a shared library in the
      shared segment region)
    o When loading a program image during the exec process

    ...all of these uses ignore the return code, and any fault that
    results later because of a failure is handled in the fix-up path
    of the fault handler.  The interface exists primarily as a
Invoke FUSE_DESTROY only after we reclaim all vnodes

Send FUSE_DESTROY only after reclaiming all vnodes. Otherwise the userspace
does not receive reclaim commands.

Patch by Anatol Pomozov
Fix a kernel panic caused by calling buf_map while holding biglock

The issue is fixed by releasing biglock before calling function buf_map in
fuse_internal_strategy and reaquiring it afterwards.

Stack trace of the panic:

    panic
    fusefs_recursive_lock_lock
    fuse_biglock_vnop_mmap
    VNOP_MMAP
    ubc_map
    vnode_pager_map
    vm_map_enter
    vm_map_enter_upl
    vm_upl_map
    buf_map
    fuse_internal_strategy
    fuse_biglock_vnop_strategy
    VNOP_STRATEGY
    cluster_io
    cluster_write_direct
    cluster_write
    fuse_vnop_write
    fuse_biglock_vnop_write
    VNOP_WRITE
    vn_write
    dofilewrite
    pwrite_nocancel
    unix_syscall64
    hndl_unix_scall64
Remove double check for VOL_CAP_FMT_CASE_SENSITIVE
access() vfs operation should have permissions check consistent with other operations
Remove useless flags

FN_ACCESS_NOOP is never set so the 'if' block is always false
FN_HAS_ACL, FACCESS_VA_VALID are not used

Conflicts:
	fuse_node.h
Remove useless flag FACCESS_DO_ACCESS

This flag set before calling fuse_internal_access() and
because this function only used in one place this flag is always set.

Conflicts:
	fuse_internal.c
	fuse_vnops.c
Remove unused variable

Fix a compiler warning.
Remove useless struct fuse_access_param

The only field 'flags' that was used in 'if' statement always evaluated
to 'false'.

Conflicts:
	fuse_internal.h
Set default error in fuse_internal_access to ENOTSUP
Fix kernel panic on OS X 10.8 triggered by mount_osxfusefs

When mount_osxfusefs fails to mount a FUSE volume it calls ioctl
FUSEDEVIOCSETDAEMONDEAD to signal that the daemon is dead. As a result function
fdata_set_dead is called before the volume is actually mounted. In this case
vfs_statfs(data->mp)->f_fsid is not set and signaling VD_DEAD causes a page
fault kernel panic on OS X 10.8.

See https://github.com/osxfuse/osxfuse/issues/38.
Don't panic in fuse_vfsop_getattr when called on an unmounted volume

The mount syscall calls fuse_vfsop_getattr immediately after a volume is
mounted. But in a tight mount/umount loop the volume might be unmounted before
fuse_vfsop_getattr returns. This might trigger a kernel panic because the
volume's private data structure is being freed while still needed by
fuse_vfsop_getattr.

This patch is merely a workaround but does not fix the underlying race
condition. In case the volume has already been unmounted and its private data
structure freed handle_capabilities_and_attributes simply returns without
setting the fields f_capabilities and f_attributes of struct vfs_attr instead
of panicking.
Fix select operation of osxfuse device

Function fuse_device_select implemented the poll interface, which is why it did
not work as expected.

Implementing the "select" operation on the /dev/osxfuse[0-9]+ devices allows
waiting for requests sent from the kernel extension to the user space FUSE
daemon in a very efficient manner while handling other events in the same
thread.

Patch by Thomas Nordin (@nordin)
Bump version to 2.5.0
Merge branch 'osxfuse-2'

Conflicts:
	fuse_device.c
	fuse_vfsops.c