Fix one read at the filesystem level turning into two transfers at the USB level
Jeffrey Lee authored
Detail:
  build/c/usbmodule - The introduction of the delayed_read flag brought with it a bug, whereby performing one read at the filing system level would result in two transfers at the USB level: One transfer triggered by the RxWakeUp device call, and a second read triggered by the Resume device call once the devices buffer becomes empty.
  To counter this a new read_status variable is used to track the state of the filesystem-level transfer; idle, busy, or complete. Only start_read calls triggered by RxWakeUp are able to start new filesystem-level transfers, while Resume is only able to continue transfers which had been paused due to lack of buffer space.
  Additionally if a RxWakeUp call is received before the previous transfer had finished, the read amount is now buffered correctly, and the read count/padding count will only be reset once the new read actually starts.
  Also made DeviceFS-level debug output more verbose and useful; most read/write debug output now lists the associated usbd_xfer_handle, making it easier to track transfers once they enter the NetBSD layer.
  build/Version - Increase USBDriver version number
Admin:
  Tested on BB-xM
  FTDIDriver now apears to work correctly again


Version 0.75. Tagged as 'NetBSD-0_75'
b6f7a82e