umount-chroot: Call umount one mount point at a time

umount, called with multiple parameters, may return 0 even if many
mount points cannot be unmounted, due to an overflow in its exit
code.

We fix this by passing `-L 1` to `xargs`.

Finally, we sort mount points in inverse alphabetic order, to
minimize the number of loops required.
unmount-chroot: -n 1 is good enough
Merge pull request #876 from drinkcat/fix-unmount

umount-chroot: Call umount one mount point at a time
croutonxinitrc-wrapper: Fix xbindkeys kill with dash

`wait "$!"` returns a >0 exit code when interrupted by a signal.
bash still executes the signal handler, then quits (-e), while
dash bails out immediately, leaving xbindkeys with PID 1 as parent.
Merge pull request #879 from drinkcat/fix-xbindkeys-kill

croutonxinitrc-wrapper: Fix xbindkeys kill with dash
targets/xorg: Install lts-saucy drivers on precise for Haswell support

We first pull in `lts-saucy` replacement drivers, then `xorg`:
- Doing it in that order still pulls in `xorg` dependencies like
  `xterm` and `xinit`, and avoids the need to specify them manually.
- Removing ``--minimal`` from the `lts-saucy` line also works, but
  also pulls in stuff like an updated kernel, which we don't want.
- Installing `xorg` after `lts-saucy` does not install old drivers
  (so there is no useless download).
- On existing chroots, installing `lts-saucy` uninstalls old drivers,
  and marks a number of packages as not required, like `xterm` and
  `xinit` (which would be cleaned later by autoclean). Reinstalling
  `xorg` does not install new packages, but makes sure these packages
  are not autocleaned.
targets/xorg: Install lts-saucy xorg whenever kernel != 3.4
Merge pull request #890 from drinkcat/precise-haswell-xorg-lts-saucy

targets/xorg: Install lts-saucy drivers on precise for Haswell/Baytrail support
mount chrootfs read-only at ~/Downloads/crouton-*

This patch bind-mounts $CHROOT read-only into ~/Downloads/crouton-$NAME
if we're logged in as a user so that we can access files in the chroot
directly from Chromium OS' "Files" application (e.g. to upload files).

In addition, mounting read-only protects us from the danger of Chromium
OS deleting files randomly from ~/Downloads whenever disk space is low:

  https://support.google.com/chromebook/answer/1061547

In fact, even the root user cannot delete files from or modify files
within a read-only mount without first remounting it as read-write!

CAVEAT: I'm assuming that Chromium OS is not so aggressive in freeing up
disk space that it would find and remount this bind-mount as read-write.