This preparatory commit moves all WAL routines to a virtual table.
Also, a helper libsql_open() function is provided. It allows passing
a new parameter - name of the custom WAL methods implementation.

Before enabling WAL journaling, libSQL detects whether WAL
is fully supported. Historically it meant either operating
in exclusive mode or supporting shared memory locks in the
underlying VFS, but it may not be the case with custom WAL
implementations. Thus, custom WAL methods can declare whether
they rely on shared memory - if not, it will also not get
verified when checking for WAL support.

It makes little sense to store the WAL file name
if the virtual WAL implementation is not based
on a single file. Therefore, WAL pathname handling
is also virtualized, with the original implementation
still producing a <dbname>-wal file.

This commit adds a stub implementation of custom WAL methods
in ext/vwal subdirectory. It can be used as a starting point
for implementing custom WAL routines.

The test case registers a new naive virtual WAL coded on top
of Rust's std::collections::HashMap. The WAL implementation
only covers reading and writing pages, without checkpointing
or savepoints, but it's enough to validate that the virtual
method table works. After registering custom WAL, a few simple
operations are performed on the database to validate that
pages were indeed stored and retrieved properly.
For extra logs, run the test with -- --nocapture.

The command is heavily inspired by .vfslist
and lists all the registered custom WAL methods.

These are customarily run early, before a call to libsql_open,
so it makes sense to auto-initialize.

With this patch applied, WAL methods can be registered
from a loadable extension module dynamically.

Not critical, as WAL methods would customarily live as long
as the program that runs it, but it's good practice to be able
to unregister during a cleanup.

WAL is open lazily on first access, while it is useful to be able
to set up ground for it even before the main db file is open.
This optional hook allows it.

Similarly to how other interfaces work, the version number in WAL methods
lets the user know which functions are supported, and which aren't yet.

The test now properly sets the iVersion and pre-main-db-open hook.

ABI should be consistent regardless of the compilation options,
so the optional functions are in there anyway - they can be simply
set to nulls if the user did not compile support for them in libSQL.

It will be useful for any state that custom WAL methods could
potentially have.

In amalgamation mode it compiled just fine, but otherwise
it relies on the wal.h header now.

The paragraph briefly explains the newly introduced mechanism.