Added the ability to generate multiple UFS partitions of differing
sizes and run the full set of freebsd install phases on a subset of
them.

disk_ufs_create now takes an optional size parameter, automatically
assigns an index 'n' to the partition, and tracks the md partition
name and full device path in DISK_UFS_PARTITION_n and
DISK_UFS_DEVICE_n, respectively.  The indexes are assigned starting at
1 and counting upwards.  The index for a new partition is available in
DISK_UFS_COUNT after disk_ufs_create returns.

`board_add_installworld_partition n` can be used to indicate that the
partition with index n should have freebsd installed on it.  The list
of such partitions is kept in BOARD_INSTALLWORLD_PARTITIONS and
defaults to "1".

disk_ufs_mount now takes a partition index to mount.  If the index is
not provided, index 1 is used.

`disk_ufs_partition [n]` can be used to obtain the value of
DISK_UFS_PARTITION_n, or DISK_UFS_PARTITION_1 if n is not provided.

`disk_ufs_device [n]` can be used to obtain the value of
DISK_UFS_DEVICE_n, or DISK_UFS_DEVICE_1 if n is not provided.

Where one would previously set BOARD_FREEBSD_MOUNTPOINT, one now must
set BOARD_FREEBSD_MOUNTPOINT_PREFIX and BOARD_UFS_MOUNTPOINT_PREFIX
instead.  BOARD_FREEBSD_MOUNTPOINT_PREFIX is used as the base of the
mount path for UFS partitions that will have freebsd installed on
them, and BOARD_UFS_MOUNTPOINT_PREFIX is used as the base of the mount
path for the other UFS partitions.  In either case, the automatically
generated suffix of the mount path is empty for UFS partition index 1
(so that the mount path is unchanged from before for
single-UFS-with-freebsd configurations), and is '.n' for the others.

`board_ufs_mountpoint [n]` can be used to obtain the mount path for
UFS partition index n, or partition index 1 if n is not provided.

board_ufs_mount_all mounts all UFS partitions.  The existing unmount
mechanism correctly handles cleanup without modification.

All existing calls to `disk_ufs_mount ${BOARD_FREEBSD_MOUNTPOINT}`
have been replaced with calls to board_ufs_mount_all, so all extant
boards transparently support the multiple-UFS feature, even if it is
not used.

BOARD_FREEBSD_MOUNTPOINT is still used to obtain the partition mount
path in strategy operations registered to run between
PHASE_FREEBSD_START and PHASE_FREEBSD_STOP, and the working directory
of those operations is still ${BOARD_FREEBSD_MOUNTPOINT}.  As the
strategy machinery will now invoke such operations for potentially
multiple UFS partitions, it takes care of setting the value of
BOARD_FREEBSD_MOUNTPOINT at the beginning of each pass through this
range of phases.  Because of this, one must take care to prevent
${BOARD_FREEBSD_MOUNTPOINT} from being expanded in calls to
strategy_add, as what you now really want is to defer the expansion of
that variable until the operation is run.  In most cases, this is as
simple as enclosing mentions of ${BOARD_FREEBSD_MOUNTPOINT} in calls
to strategy_add in single quotes.

In strategy operations registered to run between PHASE_FREEBSD_START
and PHASE_FREEBSD_STOP, the index of the current partition is
available in _CURRENT_UFS_PARTITION.  This can be used to customize
each of multiple freebsd installs differently (such as adjusting
/etc/fstab depending on partition location).

A number of status messages have been modified to be more specific
about which index, size, path, scope, etc. is involved in the reported
action.

I tried to adjust existing documentation accordingly.
Apply missed patch
Labels can now be set on FAT and UFS filesystems.
BeagleBone now loads geom_label at boot by default.
Merge remote-tracking branch 'upstream/master'
Fixed up a legacy use of ${BOARD_FREEBSD_MOUNTPOINT} in Alix/setup.sh
Added support for versioning uboot patch files os it's easier to
maintain a set of uboot patch files against one uboot release while
support for another uboot release, or master, is developed.  Also,
users may have achieved stability with a given uboot release and be
reluctant to move ahead to a later version, in which case it is
beneficial to be able to keep the older patchset around for continued
used with the older uboot release.

`uboot_set_patch_version <uboot_src_dir> [patch_version]` must now be
called before uboot_test or uboot_patch_files is called.  This sets
the new variable UBOOT_PATCH_VERSION to patch_version, if it is
supplied, or otherwise extracts the version from the uboot_src_dir
parameter.  Failing that, the result will be "unknown".  Typically,
this call will look like `uboot_set_patch_version ${<board>_UBOOT_SRC}
${<board>_UBOOT_PATCH_VERSION}`, so the user can set
<board>_UBOOT_PATCH_VERSION to select a specific set of patches.

`uboot_patch_files` returns the pattern that will identify the set of
patch files corresponding to ${UBOOT_PATCH_VERSION}.  The pattern is
currently "${BOARDDIR}/files/uboot-${UBOOT_PATCH_VERSION}_*.patch".

`uboot_test ...` no longer requires the fetch instructions to be
provided in common configurations, as _uboot_download_instructions is
now capable of generating sensible instructions when the source
version is a uboot relase version number or is "master".  Note that
_uboot_download_instructions first examines the supplied source dir to
determine the version to use in generating download instructions, and
if that fails, it assumes that ${UBOOT_PATCH_VERSION} represents the
uboot release that is being used under a non-standard directory name
and gives instructions for fetching that version to the standard
place.

board/BeagleBone/setup.sh will not try to use the
sysutils/u-boot-beaglebone-eabi port unless
BEAGLEBONE_UBOOT_PATCH_VERSION is empty.

All of the extant uboot patch files for each board have been renamed
to use the appropriate "uboot-<version>_" prefix.  In the case of
Wandboard, some of the patch files were further renamed to follow the
convention used by the other boards where the path of the file being
patched is included in the patch file name.
I've brought more uniformity to disk.sh in the way it handles the
different partition types.  All partitions created through disk.sh are
given an absolute index, as well as an index relative to their type,
by which to refer to them.  There is now an interface for storing and
retrieving arbitrary per-partition variables by name, given an
absolute disk index or a {type, relative index} tuple.  As a side
effect of this, one can now create multiple FAT and reserved
partitions as well as multiple UFS partitions.

The basic infrastructure variables that are stored for each created
partition are TYPE, RELINDEX, ABSINDEX, PARTITION (md), DEVICE (md),
BOOT, and FREEBSD.  The values are accessible through a generic
set/get_var interface, and there are also some helpers to provide for
slightly more readable access and default values when used elsewhere
in the code.

This new uniformity across partition types makes it possible to easily
construct operations that span all disks, type subsets, only ones
marked for FreeBSD install, etc.  For example, there is now a
board_mount_all that will mount all non-reserved partitions.  The
default mount phase handler is now a call to board_mount_all, and none
(or almost none) of the boards now require a custom mount phase
handler.  You can now get the mountpoint for any partition through a
call to

board_mountpoint <index>

or, say, for the second UFS partition by calling

board_mountpoint `disk_absindex UFS 2`

The installation of FreeBSD on multiple partitions is handled
differently now.  The normal set of PHASE_FREEBSD_* phases is run only
on the first partition marked for FreeBSD install (which by defaul is
the first UFS partition that is created).  There is a new phase called
PHASE_REPLICATE_FREEBSD that runs after PHASE_FREEBSD_END.  Any
partitions that are marked for FreeBSD installation through a call to
board_mark_partition_for_freebsd_install will have a replication
handler registered to run in that phase that copies the contents of
the first FreeBSD-installed partition to it.

There is a new phase called PHASE_CUSTOMIZE_PARTITIONS that runs after
PHASE_REPLICATE_FREEBSD, and a new routine to register a customization
handler for a given partition.  Via board_customize_partition,
distinct customization handlers can be registered for each partition
of interest, or a single handler that uses the new partition-variables
interface to determine which/what kind of partition it is operating on
can be registered for multiple partitions.  The user has a lot of
flexibility with which to approach their particular problem.

I've also reduced the number of references to
BOARD_FREEBSD_MOUNTPOINT, and BOARD_BOOT_MOUNTPOINT so that they are
only used from within handlers that run in the phase ranges where they
are defined, and only when the use of those variables was necessary or
more clear (that is, with a preference for working with the current
directory).

The customize_boot_partition and customize_freebsd_partition hooks no
longer are passed the mountpoint as an argument, as it is not
neccessary given that they are run with BOARD_BOOT/FREEBSD_MOUNTPOINT
defined and their current working directories set to that value.  It
should be noted that customize_freebsd_partition will only be run for
the first FreeBSD install partition, and its actions then replicated
to all the others during the replication phase.
Simplified overall and per-type partition counting.  Code is reduce,
and now only one call is required to report and track a new partition.
Merge remote-tracking branch 'upstream/master' into versioned_uboot_patches

Conflicts:
	lib/uboot.sh
Merge remote-tracking branch 'upstream/master' into disk_pull_request
Merge branch 'disk_pull_request' into versioned_uboot_patches
Merge pull request #50 from pkelsey/versioned_uboot_patches

Versioned uboot patches