Cycle priority flag on timers

Right now, due to how CSP manages duplicate timestamp cycles, all csp.timers that are scheduled will always execute in the first cycle of the given timestamp ( even if there are more data points scheduled for the same timestamp )
This can cause issues if for example you want to csp.sample with a csp.timer. In many ( perhaps most ) cases you would want to sample the last point of the timestamp rather than the first, but there is no way to control this at the moment.

The other thing we can do if we controlled priority is to allow a "last cycle" timer. This would include managing feedbacks that are introduced mid-cycle, which would then potentially allow us to implement the ever elusive "csp.reroll" ( picture ts[list] -> csp.unroll -> process individual ticks -> csp.reroll back into the original list )

Thinking out loud, we can potentially have 3 priority modes for csp.timers / alarms:

• Priority.FIRST - with first cycle for the timestamp
• Priority.LAST - with last timestamp of the cycle ( will execute after everything scheduled up to this point, but not things scheduled after )
• Priority.FINAL? ( not stuck on this name ) - ultimate last cycle of the given timestamp

LAST can be fed into csp.feedback, FINAL should raise if its wired into a feedback since that would break its semantics.

Implementation wise, we would have to introduce a priority to timestamps in the TimerHeap ( can probably embed it in the timestamp going into the existing ordered map )

Start by tracing csp.timers, csp.sample, csp.feedback, and the TimerHeap mentioned in the issue. Review how duplicate timestamps are ordered, then determine how FIRST, LAST, and FINAL priority should interact with feedbacks. Done means timer priority is controllable and the stated feedback semantics are enforced.