Compare to better-sqlite3

I started using @libsql/client originally as I don't like the blocking nature of better-sqlite3. I am using it with Nuxt and blocking the main thread due to the sync nature, is not something I want longterm.

npm:@libsql/client uses npm:libsql under the hood for non network databases. But it uses the sync api of libsql-js therefore the same problem arises. and as libsql-js has the same api as better-sqlite3 why not choose a more popular library.

And it seems that libsql-js is slower than better-sqlite3

--- reading rows individually ---
better-sqlite3 x 448,189 ops/sec ±1.49%
node-sqlite3   x 39,253 ops/sec ±0.73%
libsql         x 224,090 ops/sec ±0.1%

--- reading 100 rows into an array ---
better-sqlite3 x 16,522 ops/sec ±0.13%
node-sqlite3   x 6,771 ops/sec ±0.17%
libsql         x 9,996 ops/sec ±0.6%

--- iterating over 100 rows ---
better-sqlite3 x 13,664 ops/sec ±0.12%
node-sqlite3   x 435 ops/sec ±0.69%
libsql         x 10,843 ops/sec ±0.22%

--- inserting rows individually ---
better-sqlite3 x 119,189 ops/sec ±1.77%
node-sqlite3   x 33,240 ops/sec ±0.77%
libsql         x 95,100 ops/sec ±0.84%

--- inserting 100 rows in a single transaction ---
better-sqlite3 x 9,929 ops/sec ±1.27%
node-sqlite3   x 404 ops/sec ±0.74%
libsql         x 3,526 ops/sec ±0.95%

these are the benchmarks from better-sqlite3 modified to add libsql support. the code is just duplicated as the api is the same

Start with the duplicated better-sqlite3 benchmark code referenced in the issue and review how libsql support was added. The issue does not name a file, test, or concrete requested change, so clarify whether the goal is an async API, a performance improvement, or only a comparison before defining what done means.