Refrain from using wal2json computed column "nextlsn".

This column isn't part of Postgres Logical Decoding API and relying on it
would prevent pgcopydb from being compatible with other output plugins in
the future.

Also, our internal tracking of the LSN position was pretty confused at
times, using a single LSN value makes it simpler to follow our logic.

To still be able to follow WAL filename changes we introduce the SWITCH WAL
statement in our SQL files too, not just the JSON files anymore. The replay
process knows how to parse those SWITCH WAL statements.

To still be able to match our endpos with the actual LSN position in the
WAL, we introduce a new KEEPALIVE statement in our SQL and JSON files too.
The replay process knows how to parse those KEEPALIVE statements and mark
the progress on the replication origin tracking on the target database.