The dos slice scanner was incorrectly including extended partition entries

The dos slice scanner was incorrectly including extended partition entries
beyond the root level in the slice table, causing the slices following to
have an incorrect slice index relative to the way the kernel counts slices.
This resulted in confusion between the /boot/loader and the kernel.

We count slices by reserving the first four to exactly match the primary
slice table, but then not counting any additional extended slice entries
beyond that.  So, for example, if there are three extended tables the
in-memory indexing layout would be something like A,B,C,<ext>,D,E,F rather
then A,B,C,<ext>,D,<ext>,E,<ext>,F.  This matches what the kernel does.

Additionally, a breadth-first traversal is used rather then a depth-first
traversal.  This might not matter since most partitioners seem to use only
the first two slice entries per table (one to specify the entry and another
to chain to the next extended slice, with the last two zero'd out), but it
was done to match the way the kernel scans the slices and it appears to
be compatible with the way extended slices are created by e.g. Linux, NetBSD,
and Windows.

Submitted-by: walt <wa1ter@myrealbox.com>
		with additional modifications by Matt Dillon
Analysis-by: walt <wa1ter@myrealbox.com>