[directfd] Fix data corruption on odd sector-per-track disc I/O

[ghaerr]

Fixes data corruption and system crash at boot found when using the DF driver on floppies with an odd number of sectors per track (i.e. 360k, 720k and 1200k). The driver would misidentify a cache hit when CACHE_CYLINDER=0 and TRACK_SPLIT_BLK=0 with CONFIG_TRACK_CACHE turned on. This occurred because the driver only checked that the first sector was within the cache, but not the entire request within the cache.

In addition, when both the above internal options were set OFF (=0), the numsectors I/O value would get set to less than the I/O request size (=1 instead of 2), leaving garbage in the cache for the 2nd sector. This would typically result in a STACK UNDERFLOW error when booting under QEMU, both version 5.2.0 and 11.

Discussed heavily in #2678.

During the debugging, it was realized that the DF driver cannot easily be made to work if the FDC doesn't implement multi-track auto-head incrementing when the "MT" bit is set in a read/write command. That is, the way the driver is coded, each DMA complete interrupt must entirely finish the requested I/O, there is no facility to add remaining sectors when an I/O request w/MT set falls short.

While all known FDC hardware implements the MT bit, the MartyPC emulator does not, and thus there is no workaround when using the DF driver with 360k, 720k or 1200k floppies. 1.44M and 2.88M floppies will work, as they have an even number of sectors per track and a 1K block never straddles across the same track on double sided media.

@Vutshi, this should fix all the outstanding issues discussed in #2678, except for a possible option to force a CMOS drive setting in /bootopts when no CMOS is present. Another option would be to change the default to 1440k instead of 360k when no CMOS is present, as is the case with MartyPC.