Disable use of YUV overlay hardware in the OMAP3 HWC

Using YUV overlays causes rendering glitches and display sync loss
when playing back certain videos, so disable their use.  (It's unclear
at this point whether this is a limitation of the hardware or a driver
bug.)

Change-Id: Ia3d8fb7aadf04feaa01cbea29962e76e224052cd
recovery_ui: update for CWM API changes

CWM's eliminating device_toggle_display() and
ui_get_showing_back_button() (see http://review.cyanogenmod.org/62724).
Remove these in our recovery_ui.c.

Change-Id: Ib26ffdf04194dc0f916934bf1bc1b92b47938ee2
Add utility to set up device symlinks based on the boot device

We'd eventually like to be able to install an identical software build
for encore to either eMMC or external SD card and be able to boot it
without any modifications.  In order to do that, we'll need to be able
to find the system and userdata partitions at runtime by taking into
account the install location.

Early userspace has no way of discovering the boot location on its own,
so we modify the bootloader to pass this information on the kernel
command line.  fsfinder (this utility) will then parse the command line
to find the boot location and set up device symlinks appropriately.

To be of any use, fsfinder has to run before /system is available, so
to avoid the need to ship a statically linked shell or other interpreter
in early userspace, the implementation is in C and compiles to a
statically linked binary.
Make the early boot process boot-location-agnostic

Instead of using fixed block device names for /system and /data, let
fsfinder set up links for us based on the boot location.  This allows us
to run unmodified from both eMMC and external SD card.
Make the recovery boot-location-agnostic

Instead of using fixed block device names for /system and /data, let
fsfinder set up links for us based on the boot location.  This allows us
to run unmodified from both eMMC and external SD card and to do the
right thing in both cases.
Add script to configure vold based on boot location

On SD card installs, the first partition of the SD card is the FAT
filesystem used as the boot partition.  This leads vold, which searches
the SD card for the first recognized partition when given a partition
number of "auto", to identify /boot as the /sdcard partition.

Fix this by running a script which detects SD card installs and modifies
/fstab.encore to instruct vold to use the last partition on the SD card
in that case.
Configure vold based on boot location in recovery too

To ensure that configure_vold.sh runs before vold starts, we need to use
an init.rc file (postrecoveryboot.sh is run when recovery starts, after
all the various services are started).

We also need to edit the configure_vold.sh script to change the
interpreter location for the recovery (/sbin/sh as opposed to
/system/bin/sh), so we need some build system hackery as well.
Recovery: move fsfinder startup into init.rc

While it doesn't seem to be strictly necessary for fsfinder to be
complete before the recovery starts, it shouldn't hurt either, and it
may prevent some potential problems in cases where recovery has been
instructed to do something when it starts (flash an OTA package, for
example).
configure_vold.sh: clean up identifying last partition on SD card