3.43.2 and move SqliteClient to separate entrypoint

[DallasHoff]

I have been developing a library based on this package, but I have been stuck on 3.42.0-build2 for a while because the next version added SqliteClient, and I have been unable to resolve build errors resulting from this change. In this PR, I would like to move SqliteClient to be exported from @sqlite.org/sqlite-wasm/client. This fixes the build complexity and allows packages based on @sqlite.org/sqlite-wasm to use it without needing to import Comlink or the client code that they may not need.

(No disrespect intended toward the work on SqliteClient by @etiennenoel. When I first started experimenting with this package, I was given the impression that it was not intended to extend the sqlite.org code in anyway, only to provide it on npm, so I started working on my own client library. SqliteClient was added here later.)

Additionally, this PR bumps the dependencies from sqlite.org to 3.43.2. Just from running the normal build script.

[steida]

I would also like to use this package without a comlink.

[tomayac]

@etiennenoel Would you be open to removing SqliteClient again and republishing it as a separate package? In the longterm, the SQLite Wasm npm package should probably stay as closely as possible to the original source as published by the SQLite team. We can add types as a convenience (#2), but this should probably be it.

Sorry, I was wrong in suggesting/agreeing to adding SqliteClient, as it has side effects (#42, #43 [this Issue], #44) not related to the main library that add noise to this repo.

[etiennenoel]

I can understand that, I think that's why at first I was trying to prevent adding any dependencies.

I'll re-create a repository and move things out of here. I believe that some developers will want an easy plug-and-play solution while others will want control over how things are implemented.

[tomayac]

@etiennenoel has agreed for SqliteClient to be removed again and to move it to a separate package. I will close this PR then, and apologize again to @etiennenoel for the hassle and to current users of the feature who will soon need to switch their dependencies.