WIP: time skipping turns to versioned transition for task validation

[feiyang3cat]

What changed?

1. remove event ID from and add archetypeID to the time skipping timer task
2. add VersionedTransition in time skipping timer task/time skipping info for cross/intra cell task validation

Why?

1. chasm executions don't have event ID and need archetypeID for loading ctx
2. VersionedTransition.FailOver can help find out stale tasks during failover and failback
3. VersionedTransition.TransitionCount can help find out stale tasks when fast-forward is overwritten

How did you test it?

• built
• run locally and tested manually
• covered by existing tests
• added new unit test(s)
• added new functional test(s)

[yycptt]

I don't have super strong opinion but ideally I think we should use the (LastUpdate)VersionedTransition concept/primitive here (which is invented for this validation purpose) and be consistent with how we are tracking "component" updates and validating component tasks in the state-based replication & CHASM world.

I understand all existing workflow transfer/timer tasks are using their own version field, but that's something we are gradually moving away from as we migrate more and more components onto CHASM. and hopefully one day we can have only one approach for tracking and invalidating tasks.

cc @xwduan

[feiyang3cat]

need to confirm my understanding :

there won't be a case where there is time skipping feature in the system while versioned transitioned returned nil (= transition history is not enabled

[feiyang3cat]

I think it is better we have a unified way/generic way to check unexpected invariants failures in tasks, they shouldn't be retried, but need logs/metrics and optionally need dlq (and I didn't add dlq needed flag as right now dlq is treated not as a per-task choice by design and I don't want to couple this pr with this change).

adding a generic implementation of this MaybeTerminalTaskError maybe a choice, but
need a closer look at this design if this is the best one