CDS: differentiate between messaging and persistence versions

Our current versioning assumes we are using same versions across the board. This may become problematic when we actually allow mixed deployments, as an up-revved leader can produce persistence events which are not understandable by followers.

We need to define a clear behavior strategy of either discovering the quorum version for a particular Shard, or preventing down-revved followers from becoming leaders.

Versions of persisted events are clearly not related to frontend message versions, so it does make sense to separate the two. The newly-defined versions should be enums, so we have type safety and do not accidentaly mix the two.