Persist pending db_version in transaction guard vtab xSync

[gorbak25]

A statement can be rolled back via the statement journal without rolling back the enclosing transaction:

CREATE TABLE foo(id INTEGER PRIMARY KEY);
BEGIN;
-- The first row inserts and fires all AFTER INSERT triggers;
-- the second row fails and the whole statement is rolled back.
INSERT INTO foo VALUES (1), (1);
-- The transaction is still open, so this succeeds.
INSERT INTO foo VALUES (2);
COMMIT;

We assign a new db_version inside triggers. If the statement is rolled back, the write of that db_version is undone too, but our in-memory state still says it was persisted, so we never write it again. After commit, a new connection sees the old db_version and reuses it. Rolled-back savepoints hit the same problem. #26 added more savepoints, which makes this the likely root cause of https://status.flyio.net/incidents/s9dzwg3d4bs7.

This PR moves db_version handling into a wrapper vtab that persists the pending db_version in its xSync callback, so it is always written at commit regardless of statement or savepoint rollbacks.

The trade-off is that transactions like this can leave gaps in db_version:

BEGIN;
SAVEPOINT test;
INSERT INTO foo VALUES (2);
ROLLBACK TO test;
COMMIT;

Gaps are safe, unlike reuse. If they become a problem, we can fix them by tracking savepoints properly.

[somtochiama]

a few nits but LGTM!