Document (and maybe revisit) assumptions on comparability between default instances

[chrysn]

The way this is used in choreographer (timers are not carried around ever but only created briefly and polled) implies that it's an assumption in groundhog that tick values can be compared between different (created-through-Default) instances of a RollingTimer, and that the timer keeps rolling even when no instances are around.

For a concrete backend I'm having in mind (RIOT's ztimer) this is not given, and I was one merged upstream PR short of implementing RollingTimer on it. I see two ways forward from this:

• Document that it is so.

  It's a valid way, but makes it likely unusable on RIOT -- or the implementation would need to work around it by having a global static timer that creates a hidden ZTimer lock in a hidden global mutex at first use.

• Document that it is not so. (Or state that this is the intention).

  This would necessitate changes in choreographer. I'm not sure if the actions all have good access to a single stored RollingTimer. If so, it's easy. If not, they might .clone() one around. Note that implementations that comply with the current model would probably all be zero-sized, and can have zero-cost .clone() methods.

If you lean toward the second way but don't want to do the changes, that's something I can work with too -- in that case, I (if and when I use choreographer on RIOT ... or whoever next stumbles on this) could see that changes along these lines would be welcome to choreographer, and once PR'd the semantics could be changed.