Add support for prepared statements

[yerTools]

Hello :)

I added support for prepared query statements to improve overall performance when queries are reused.
Since both libraries (Erlang and JavaScript) use prepared statements under the hood when calling query, I split this function into prepare and query_prepared.

I also updated every test that uses sqlight.query by introducing a helper function that ensures both functions return the same errors and results.

I had to wrap the database connection in sqlight_ffi.js to keep track of the created prepared statements since the library requires that they be finalized before closing the connection. I think this isn't the most elegant solution, but I'm not aware of a better approach.

I also updated the README example, the CHANGELOG, and bumped the version to 0.10.0.

Thank you very much for the great work, and I'm hoping I didn't miss anything this time. :)

[lpil]

Looks great! Thank you.

Could you write a test for what happens when the connection has been closed and then the statement is run. Thank you

[yerTools]

Thank you very much for the code review. I wrote some tests and got inconsistent results depending on the target platform.
Since you have more experience, I wanted to ask for your opinion before addressing these missing tests.

---

1. Running a normal query after the connection was closed:

• Erlang panics with the failure badarg.
• JavaScript returns an error: SqlightError(code: GenericError, message: "Database was closed.", offset: -1)

This inconsistency existed before this PR.
Can this behavior be tolerated, or is it a bug? If it's the latter, how should it be fixed?
I think it's better to return an error than to panic, but I currently have no idea how to prevent the panic.

---

2. Running a prepared statement after the connection was closed:

• Erlang returns the expected result (perhaps because the query is very simple?).
• JavaScript returns an error: SqlightError(code: GenericError, message: "Query is finalized.", offset: -1)

Since Gleam is immutable, I don't know how to keep track of whether the connection has been closed, other than wrapping the whole thing inside a process—which either breaks target support or introduces overhead.
I think returning an error would be the right way to handle it, but I'm not sure of the best approach.

---

I'm looking forward to your opinion on this topic. The best solution I currently have in mind is to document it as undefined behavior on the close function. You probably have a better solution. :)

Thank you

[yerTools]

Hello,

I used this version in a private project of mine, and tests failed. After a few hours of debugging, I found the problem. If you don't reset the prepared statement after an error occurs, this error will reappear when the prepared statement is used again.

This is now solved, and I added the test case which triggered this bug by not resetting the prepared statement after each use. I also set a flag to indicate that these prepared statements are persistent.

Thank you very much! :)