FFI loading alternatives

[corrideat]

Problem

We currently use FFI for loading sqlite3 (via jsr:@db/sqlite3), which is problematic because it'll add code from jsr:@denosaurs/plug. That code has a few issues (for example, it'll require read and write access to $DENO_DIR, network access and it'll download a dynamic library without integrity checks from the Internet).

We've already thought of some mitigations (see #73), but downloading a dynamic library from the Internet can already be problematic, since it could contain any arbitrary code, and it'll run outside of Deno's permission sandbox.

As for why this happens, there are a few reasons I can think of:

1. The library is loaded using Deno's FFI interface, which uses dlopen. I'm not entirely sure yet, but this might require a separate file for it to work.
2. Downloading a file from the Internet is flexible because the correct file can be downloaded. The library needs to be for the correct operating system and architecture.

Solution

Ideally, we'd want chel to be a standalone binary without having to download (potentially)) arbitrary binaries from the Internet. Solving this issue might also de-prioritise #73, since perhaps then we won't need --allow-read=/ in the binary.

There are a few ways to go about it:

1. We could ship chel and libsqlite3.so (and its variants for different platforms) as separate files and instruct users to use DENO_SQLITE_PATH. However, this isn't very user-friendly.
2. We could see if there's a way to bundle libsqlite3.so (and its variants for different platforms) in the chel binary. Doing this requires:
   a. Being able to use dlopen under these circumstances
   b. Using the correct library for the platform and architecture the binary targets
   c. Modifying the bundle (or the way it works) to load the library this way
3. We could switch to a different library that doesn't rely on FFI, such as a WASM version (note that this might result in a performance penalty).