Debug aes-fvsr-key-batch timing issues

@vrozic is already working on this.

Since Oct 19, 2023.

PR #82 added the corresponding target binaries to support the aes-fvsr-key-batch command. For most of us this seems to work just fine but I saw lots of errors like:
```
Fixed key: b'811e3731b0120a7842781e22b25cddf9'
Connected to ChipWhisperer (num_samples: 1200, num_samples_actual: 1200, num_segments_actual: 1)
Capturing: 16%|███▋ | 162/1000 [00:00<00:01, 492.97 traces/s]
Traceback (most recent call last):
File "./capture.py", line 771, in
app()
...
File "./capture.py", line 502, in aes_fvsr_key_batch
capture_aes_fvsr_key_batch(
File "./capture.py", line 460, in capture_aes_fvsr_key_batch
check_ciphertext(ot, expected_last_ciphertext, 4)
File "./capture.py", line 221, in check_ciphertext
assert actual_last_ciphertext == expected_last_ciphertext[0:ciphertext_len], (
AssertionError: Incorrect encryption result!
actual: bytearray(b'^\xdc\xe8{')
expected: [ 85 154 226 3 30 12 31 147 54 197 151 35 4 134 80 98]
```

In words, there are sometimes mismatches between the expected and received ciphertexts. Sometimes, the failure occurs for the first batch, sometimes for a later batch, sometimes it doesn't occur at all. The failures seem to depend on timing (adding some sleep command on the Python side seem to help), Husky firmware (the latest firmware seems to be more affected), and maybe also USB connection setup (docking station, hub, laptop directly).

We should root cause and fix the problem. Otherwise we can't reliably do long running captures. Imagine we collect 10 Mio traces and get such a failure after 2 hours - all traces will be lost.