Sanity-check persistent resolved timestamp

[bobvawter]

Consider adding a sanity-check which ensures that any data being written into the staging table is not stale with respect to any previously-received and -flushed resolved timestamp. This would indicate a possible desynchronization of the changefeed and should result in a permanent failure condition.

[bobvawter]

Work in #73 adds a check to ensure that a resolved timestamp doesn't go backwards when it's persisted. Might be worth it to hold the previous resolved timestamp in memory to detect re-delivery of stale messages if we add additional transport mechanisms.