fix(archive): patch the sqlite driver to solve results inconsistencies

[LNSD]

This is a temporary patch until the SQLite library is improved. Making the SQLite manage a copy is far from ideal. Binding the parameters with this "destructor configuration" option, implies that SQLite is making a copy of the buffer. This is inefficient. A more performant solution should be investigated.

From SQLite C documentation (link):

The fifth argument to the BLOB and string binding interfaces controls or indicates the lifetime of the object referenced by the third parameter. These three options exist:

1. A destructor to dispose of the BLOB or string after SQLite has finished with it may be passed. It is called to dispose of the BLOB or string even if the call to the bind API fails, except the destructor is not called if the third parameter is a NULL pointer or the fourth parameter is negative.
   2.The special constant, SQLITE_STATIC, may be passsed to indicate that the application remains responsible for disposing of the object. In this case, the object and the provided pointer to it must remain valid until either the prepared statement is finalized or the same SQL parameter is bound to something else, whichever occurs sooner.
2. The constant, SQLITE_TRANSIENT, may be passed to indicate that the object is to be copied prior to the return from sqlite3_bind_*(). The object and pointer to it must remain valid until then. SQLite will then manage the lifetime of its private copy.

The tests I have performed so far seem to confirm that these changes solve issue #1400. But to be 100% sure, more thorough testing needs to be done.

[jm-clius]

I assume this means it handles the malloc but always free it again - more memory but (hopefully) not leaky memory?

[LNSD]

We call the sqlite3_finalize function later in the code to release the prepared statement memory.

This is what the documentation says about the SQLite statement destructor:

The application must finalize every prepared statement in order to avoid resource leaks.

I interpret this as deallocating any memory associated with the prepared statement. Bindings included.

[jm-clius]

Really great work. Quite something to find this. Well done!

[LNSD]

macOS test2 job failing due to the same offending test case. Test failure already tracked in #1357. Merging without re-running the checks and Ubuntu test2 job is passing.

[rymnc]

LGTM