[dv,usbdev] Remaining DV improvements

### Description

This item gathers a few lingering, perfective DV improvements following the push for V3:

- [x] usbdev_iso_retraction probably deserved a little experimental adjustment of time delays to achieve the desired frequency of collisions between device- and host-side activity, although they have been seen to occur often with the current numbers.
- [ ] usbdev_iso_retraction could perhaps be more effective if the packet size is variable rather than maximum length; the latter increases the chance of attempting retraction whilst transmitting, though.
- [ ] host-side code is frequently waiting on the wrong clock; this is not ideal now that there are multiple independent clocks within the DV and we have the capacity to vary host clock relative to the DUT clock.
- [x] max_usb_traffic sequence is very flexible but presently does not support Isochronous traffic too. Obviously this is covered in a number of other sequences, but it would be good to intermix Iso streams too.
- [ ] the driver and monitor should perhaps not be operating synchronously on a 4x oversampled clock; there is no particular reason to have periodicity in the operation of this logic; it could just await transitions on the USB and respond as per a real DPLL. This could perhaps give is greater confidence in the frequency/phase adjustment of the DUT.
- [ ] move the observation of inter-packet and turn-around delays to the driver itself rather than the vseqs, to simplify things and to reduce the likelihood of unintended violations; support any intentional violations using meta data to the driver.
- [ ] the monitor steals the driver output enable from the DUT to ascertain whether the driver or the DUT is producing the traffic; at the very least it would be preferable to use information from the driver itself, and them make absolutely sure that we can detect a bus clash.
- [ ] consideration must be given to the running of multiple sequences back-to-back and the impact of configuration `plusargs` switches to enable/disable any checking (if it cannot always be enabled in time), and to ensure that everything handles random resets properly.
- [ ] usbdev_fifo_rst sequence presently does not exercise the RX FIFO properly.

Start by mapping the usbdev DV sequences, driver, monitor, vseqs, and usbdev_fifo_rst sequence mentioned in the checklist. Review how clocks, plusargs, resets, inter-packet delays, and driver output-enable information are currently handled. Done means selecting and implementing a clearly scoped improvement with verification that the affected traffic, FIFO, reset, or collision behavior is exercised.

Written by the indexing model from the issue text.