Initial snapshot of work to eliminate 64K MAXPHYS.  Basically works for
physio (I/O to raw devices); needs more doing to get it going with the
filesystems, but it shouldn't damage data.

All work's been done on amd64 so far.  Not hard to add support to other
ports.  If others want to pitch in, one very helpful thing would be to
sort out when and how IDE disks can do 128K or larger transfers, and
adjust the various PCI IDE (or at least ahcisata) drivers and wd.c
accordingly -- it would make testing much easier.  Another very helpful
thing would be to implement a smart minphys() for RAIDframe along the
lines detailed in the MAXPHYS-NOTES file.
Support transfers of up to MACHINE_MAXPHYS in all pciide variants, and ahci.
wd(4) limits its maxphys depending on the drives's capability (64k sectors
for LBA48, 256 sectors for LBA and 128 sectors for older devices).

I assumed all pciide controllers could do MACHINE_MAXPHYS transfers, but
this may not be true. The capabilities of each controller variants should be
looked at more closely.
Fix panic "bad chunksize ..." in read-ahead code:
- off comes from the pager, so should already be page-aligned.
  KASSERT() that it is, and remove the off = trunc_page(off)
- as off is not changed any more, the size of the transfer is chunksize.
  Don't compute bytelen any more,  which is what required chunksize
  to be a power of 2. KASSERT() that chunksize is a multiple of page size.
Redo previous: it seems that the point of the bytelen computation was to
get transfers aligned to chunksz. So reintroduce the code, but using chunksz
instead of chunksize (if the readahead is trucated there's no point in
trying to align it anyway).
Now I get 64k read requests at the drive level again.
Use mnt_maxphys not MAXPHYS to limit the size of I/O to disk.
Now the read-ahead code does issue 512k requests to disk.
We know vp is not NULL, no need to check
The pagedaemon ca emit write as large as the underlying device's maxphys,
so emergva size needs to be MACHINE_MAXPHYS, MAXPHYS is not enough.
In the FFS writebehind code (ufs_readwrite.c:WRITE()), use division
and multiplication instead of shifts, to accomodate devices with
MAXPHYS that is a multiple of the page size, but not a power of 2.

MegaRAID neatly writes out 192k chunks now.

An open question: is is really a good idea to always writebehind
at the largest size supported by the device?  Likely not, as this
could have a major impact on I/O fairness.  OS X and Solaris both
seem to limit transfers to 128k likely for this reason (the same
problem exists with the readahead code but since it is adaptive,
it will not *always* do huge transfers).

However, simply imposing a smallish limit like 128k here seems
like a bad idea because then we cannot accomodate greedy devices
like RAID, for which you want something like 128k * number of
data components.  Hmmmmmm.
Add a minphys routine for raidframe.

For now, we will address the problem of someone adding, at runtime with
a filesystem mounted, a drive to an existing RAID set, that drive being
on a different controller or bus such that it has a smaller maximum
transfer size than the smallest such size of any component previously
in the set, by clamping RAIDframe's reported maximum transfer size at
the old MAXPHYS value multiplied by the number of data disks in the
set.

In the future, we could either implement transfer-splitting to
the device specific maxphys in a generic way for all disks (Manuel's
proposal, and probably the best solution) or simply forbid adding
new components to RAID sets while running if those new components
have a smaller maxphys than that of any component already in the set
(my proposal; less flexible but a lot less code to write).

Anyway, now you should be able to see your 5 disk RAID5 set do
256k transfers through the filesystem -- 64k per component
instead of 64K total.  A win!