Libsql client transactions: remarks and todos

This is related to #653 . Things to discuss are:

1. Transaction correctness. Should the begin transaction statement be batched with the first statement to save a roundtrip? IMO this messes up with the transaction execution order, since server is not aware of transactions opened on the client side. Saving a roundtrip is arguably not a big deal, since opening interactive transaction already assumes that we're going to do a "chat" with the database with multiple roundtrips involved (users can use query/execute/execute_batch for things that don't require interactivity).
2. How should we rollback execute_batches that failed mid-way when executed within transaction scope?
3. Extract Hrana protocol message contracts so that they could be shared between libsql client and server.
4. How to defer Cloudflare transaction rollback on dropped transactions? Right now Transaction over Hrana HTTP variant is capable of scheduling rollback request when it's being dropped without being rolled back or committed explicitly. However that's not the case for Cloudflare workers: we need (?) to figure out a way to utilise workers API to gracefully close uncommitted transactions.

Start by reading the transaction and execute_batch behavior in the libsql client, then compare the Hrana HTTP and Cloudflare Workers transaction paths. The work needs decisions on batching, rollback after partial failure or dropped transactions, and shared protocol contracts before implementation can be considered done.