C client: re-using SQLite interfaces that don't do I/O

[cole-miller]

An important goal for the C client library is that porting an application from SQLite to dqlite should be convenient, involving as few invasive changes as possible. It's not possible to re-use functions like sqlite3_prepare_v2 or sqlite3_exec because the corresponding operation in dqlite needs to do novel things like connect to a leader and speak the wire protocol, but in principle it seems like we should be able to re-use many parts of the sqlite3 API that don't don't do any I/O. For example, it would be great if packing values into a tuple of statement parameters or unpacking a sequence of rows could work with no code changes when doing this migration.

The second-best interface would have dqlite* functions for all these purposes whose signatures are completely analogous to the sqlite3* function, so that most of migrating a codebase is just replacing the first part of the name of various functions.

A couple of issues:

• Key structs like sqlite3_stmt are opaque, so we can't just embed them in our own dqlite_stmt.
• Re-using any sqlite3 function commits clients to linking in libsqlite3. For the high-level client that's not an issue because libdqlite already links against libsqlite3, but we should think about what a potential "thin client" would have to do.

[cole-miller]

Worth noting that even if we can't re-use many sqlite3 functions, we should be able to re-use the constants.

[cole-miller]

Closing this since it's not really tracking anything.