Add db.setWalHook()

[jamiebuilds-signal]

This adds the ability to call sqlite3_wal_hook() to setup a JS callback.

The callback is invoked by SQLite after the commit has taken place and the associated write-lock on the database released, so the implementation may read, write or checkpoint the database as required.

Importantly, setting your own WAL hook replaces/disables sqlite3_wal_autocheckpoint:

From sqlite3_wal_hook()

A single database handle may have at most a single write-ahead log callback registered at one time. Calling sqlite3_wal_hook() replaces the default behavior or previously registered write-ahead log callback.

From sqlite3_wal_autocheckpoint

The sqlite3_wal_autocheckpoint(D,N) is a wrapper around sqlite3_wal_hook() [...]

If the JS callback throws, the WalHookWrap::Call function will swallow the exception and return SQLITE_OK. The alternative is that that the statement that triggered the commit would throw.

The callback function should normally return SQLITE_OK. If an error code is returned, that error will propagate back up through the SQLite code base to cause the statement that provoked the callback to report an error, though the commit will have still occurred.

The implementation is basically the same as db.createFunction() but it differs in how it gets cleaned up since we don't have the xFinal param to call the destructor at FunctionWrap::Final. Instead its stored at Database::wal_hook_wrap_ which then needs to be cleaned up on database close.