Detect filesystem types supported by kernel

When setting up the union filesystem, instead of relying on the Ubuntu distro
name to detect what type of filesystem to use ('aufs' or 'overlayfs'), detect
the filesystem types supported by the kernel based on the contents of the
/proc/filesystems file.

This commit also tries to load the union filesystem modules via modprobe, in
case the kernel supports the filesystem type but the module is not loaded at
boot time.
Merge pull request #52 from cloudfoundry/union-fs

Detect filesystem types supported by kernel
Revert "Detect filesystem types supported by kernel"

This reverts commit 61b80603199cd59b20af34d606a3d8b5ba40e483.

This appears to break nested Warden, which currently abuses the previous logic
to fool it into using overlayfs instead of aufs. This commit prevents that hack
(which is nice) but we probably don't want to break nested Warden at the same
time.
dynamically determine aufs vs. overlayfs vs. other

This replaces the previous logic of checking for Ubuntu, and specific
versions, with dynamic detection of whether to use aufs or overlayfs.

If the filesystem is detected as aufs, it makes sure not to try mounting aufs
or overlayfs. This is because aufs cannot be mounted on a branch within aufs,
and OverlayFS *will* mount, but will fail to delete any files. This is because
aufs does not support xattr, which OverlayFS uses for whiteout.

Both aufs and overlayfs will be attempted, in that order. If neither can be
used, we fall back to the basic yet portable bind-mounting + copying strategy.
silence quotaon errors

these are used as conditionals; error is expected
don't use aufs if we're allowing nested warden
don't mount aufs or overlayfs in overlayfs

overlayfs can be mounted in overlayfs, but has the same whiteout problem as in
aufs. aufs mounts but has strange behavior.
clean up nested warden specs

* no longer install ruby with rvm; the ruby in the rootfs should be fine. this
  shaves many minutes off running the tests.
* with DEBUG=true, stream the output of the commands that are being run in the
  container. this gives more information when it fails than '1 should be 0'.
* destroy the outer container in cleanup
* don't trash dev/* in the rootfs. this only affects overlayfs in overlayfs,
  which will no longer be the case for these tests, as it will properly fall
  back to the copying + bind-mount mechanism.
only print exit status if debugging