Cleanup retry logic in I2C drivers, implement better retries in main event polling loop, remove delays, possibly return NaNs

A few of the sensors are more unreliable than most.
They fail before a data read and return false.
The firmware then loops over the event polling code again and detects the sensor is still overdue.
This repeats.
If they failed forever, then the code is basically in a tight loop polling the sensor indefinitely. The serial monitor can become flooded (along with the UI if available, but so far the main issue is around whether to retry inside the driver).

A few of the I2C drivers retry the data read inside the driver code to ensure the user's best chance of recording their desired data.

This deviates from the idea of being a short rapid interrupt-like method to fetch the data by using delays between read attempts.

In an ideal world they would quickly fail, and the main event loop would retry them a sensible number of times before marking the event as passed and updating the next poll time.

It's possible we may want to send a NaN in this situation (although the current thinking is NaN means something specific - i.e. that a target is not currently in the area for a proximity sensor), or bubble up another kind of error / msg to the IO website and accept the sensor data read event returned unsuccessfully.

Again there is a fair bit of code repetition for retries, and the main thing that came up was trying to monitor the millis while checking the result of a conditional, a possible rollover situation, which leads to a horrific looking for loop with the main execution block indistinguishable from the conditions (VL53L4CX development #564 ).
It was an interesting excercise to explore the idea of a RETRY_UNTIL_TIMEOUT macro, but unnecessary if we fix the main event loop to retry more efficiently. For posterity: https://chatgpt.com/share/b760dd1d-5bdf-4f5d-b3ae-ec762eab6207

Start by tracing the main event polling loop and the retry paths in the I2C drivers, including the VL53L4CX work referenced in issue #564. Compare the current driver delays and repeated polling behavior, then determine how failures, retry limits, poll timing, and possible NaN or error reporting should be handled. Done means the retry policy is consistent and permanently failing sensors no longer create a tight polling loop or flood the serial monitor.

Written by the indexing model from the issue text.