Implement FDC write mode about vector06cc HOT 6 CLOSED

Woo. Hoo.

Even with DMA. Mutisector mode not tested as nothing seems to be using it, just 
like
mutisector read.

Better reopen it.

Rewrote big part of the state machine, command begin-closure mating.. Now both 
BIOSes
seem to be more happy than not, but there's still an occaional miss every now 
and then.

Here's an excerpt from an erroneous write operation:
{{{
430347+`430348+`430349+`43034a+`43034b+`43034c+`43034d+`41034d+
rHST:01034d:00+
4dwHST:00034d4d:00
4d 41 49 ce 05 02 80 35 02-00 00 00 00 00 00 00 MAI....5........
}}}

According to directory entry, the data was supposed to be written to 
HST:01:03:4d,
which is 5 sectors earlier than it was written here (side 0). Who switches 
sides, duh! 

(test case: boot from cullshit.fdd, run
  cc1 aa -az
  cc2 aa
the operaion above is from writing aa.crl)

Some analysis:
if MASTER_COMMAND is printed when entering Write command handler, in faulty 
cases it
retains the value $80, that is ACK. Roughly this means that:

WD issued a WRITE request
WD decided that operation is complete faster than CPU acknowledged BUSY
WD issued CPU_REQUEST_ACK before CPU even started to process ?

CPU_REQUEST_ACK comes from $D0/INTERRUPT command

Mostly done. BDS C chaining is probably related, but it's a new issue.