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.