Fix flushed capture data being missed at shutdown

[martinling]

This PR does a fair bit of refactoring of the Cynthion capture backend, in order to solve a quite simple problem.

The bug was that during shutdown, Packetry was tearing down the data transfer queue before sending the control request to stop capture. This meant that capture data which was flushed by the analyzer at stop time was lost. In most cases, this wasn't noticeable, but when using low-traffic devices (especially LS keyboards), a whole capture could be lost entirely, if it never produced the 512 bytes needed to fill a packet to the host.

Test case:

• Start a low speed capture.
• Plug in a USB LS keyboard.
• Stop capture.
• No traffic is captured.

To fix this there were basically two options:

1. Do a bunch more fiddly work to integrate the start/stop control requests into the same async task as the data transfer queue handling, including re-implementing timeouts for them.

2. Spawn an additional worker thread for the data transfer queue processing, allowing the existing capture thread to continue to use nusb's synchronous API for control requests.

I spent a bunch of time trying to do option 1. It's ugly and difficult. So this PR implements option 2.

This choice also helps with the upcoming HITL test work, where we need to send additional control requests during capture, to manage the test device on the AUX port. Option 1 would have required these too to be integrated into the async task.

To simplify the HITL use case further, this PR also makes CynthionHandle::start() clone self to pass to the worker thread, rather than consuming it, meaning the test can keep that handle to make its additional requests with.

[miek]

LGTM. This also now successfully catches the issue we saw in greatscottgadgets/luna#264 without needing to get it on the scope: