🐛 - fix an issue where we would not converge in certain P2P scenarios

[tantaman]

When we switch from the vector clock to lamport clock design, we ended up conflating two concepts:

1. the clock of the database used to track missed changes
2. the clock of a column used to do merging

The original vector clock approach kept a version per column independent of the clock of the database.

When we merged the two ideas we created a situation where any time a merge changed a column value, we would set the clock of that column not to the winner's version but to MAX(winner_version, crsql_nextdbversion())

This would cause a column to have its version number re-assigned.

Example:

Peer P @ db_version 100:
[id1, A, v_6]

Peer Q:
[id1, B, v_7]

merging Q to P would put P in this state:

[id1, B, v_100]

Making id1,B look much newer than it ought to be.

which is ok (at least from a convergence perspective, maybe not user expectation perspective) in a client-server sync but not in p2p sync. This would cause state results to differ based on which peers sync with which first and require many rounds of messages to converge. When optimizing to "not sync self sourced changes" this can hit cases of non-convergence.