cosmo-hf: add limited busy-polls in all wait paths

[hawkw]

Presently, the cosmo-hf driver has three functions that wait for some status to change before continuing: wait_fpga_busy, wait_fpga_rx, and wait_flash_busy. All of these functions check the desired condition in a loop and sleep for 1ms when it is not satisfied. Currently, wait_fpga_busy will first perform a limited number of busy-polls before starting to sleep between polls, but the other functions do not. While investigating HF write performance on Grapefruit,
@cbiffle and I found that commenting out the sleeps in these polling functions improved HF write performance significantly: writing 2MiB of random data using humility qspi -D went from taking about a minute to about 36 seconds --- that's a 40% performance improvement.

This branch is like a slightly more principled version of commenting out the sleep_for calls. I've generalized the pervious wait_fpga_busy of doing 32 busy-polls before starting to sleep to something that can be used by all three wait-for-condition type functions. I did change the code for implementing this a bit from the previous thing, which implemented the counter using a for i in 0.. loop that checked i > 32 This was a bit more concise and kind of a cute trick, but had a somewhat surprising behavior: the loop wasn't actually infinite, and would terminate after u32::MAX polls. Of course, polling for 4,294,967,295ms means we would have waited about 50 days for a write to complete before terminating the loop unexpectedly, and if that happened, something would have to be REALLY broken. But, it's still a pretty wrong behavior, so the implementation I've done --- using a while loop with an explicitly incremented counter --- will never terminate unless the condition has actually changed, which seems a little less anxiety-inducing.

[hawkw]

I don't have a Cosmo or Grapefruit readily available for testing this, so I've opened it as a draft for now. If @mkeeter or @cbiffle wants to give this a quick smoke test, I can un-draft it, otherwise I'll go into the office some time next week and try it out on a Grapefruit from the executive bathroom.

[hawkw]

32 may be more busy-polls than are really necessary, at least for wait_fpga_rx; @cbiffle and I saw it take about one poll before becoming ready pretty consistently, on Grapefruit. But, I figured we'd keep the current number for now.