`rtic_monotonic::nrf::rtc` errata workaround is probably not what was intended

[Finomnis]

The errata says that the RTC timer only fires if the scheduled CC is at least 2 ticks in the future.

The workaround for this was to provide the Monotonic::should_dequeue_check function, which, if the leftover duration is less than 4 ticks, dequeues and wakes the future.

The timer's delay_until function sadly doesn't know anything about that, so it reacts with re-inserting the delay back onto the timer queue and triggering an interrupt.

The interrupt again dequeues it and wakes the future.

This infinite loop goes on for up to 4 timer ticks, or 122us. Due to the fact that this ping-pong involves the timer interrupt, which has the highest priority on the system, most certainly this will cause disturbances on the rest of the tasks.

---

There are two ways to mitigate that:

1. Check should_dequeue_check inside of the delay_until function, to prevent re-queueing. Then, simply wake the waker and return Pending, so that the busy-waiting is limited to the low priority task and no longer involves the interrupt handler.
2. Schedule the queue wakeup 4 ticks in the future, even if there are tasks that would have to be woken earlier. embedded-hal's DelayNs specifies waiting "at least ms milliseconds" anyway.

So, it is a tradeoff between "in time, but higher power usage" (busy waiting) and "delayed, but low power usage" (schedule the wakup late)

A discussion in chat resulted in that it is propably best to go with the second option, as people who use the RTC driver most certainly prefer low power usage over 150us latency.

Further discussion is required.

Another question is also what we do with Monotonic::should_dequeue_check, as it's already published, and removing it would be a breaking change. If we go with option 2, I think we should at least deprecate it.