feat: cache prepare statement for reuse

[BobdenOs]

Currently @cap-js/hana will always call prepare for queries that have placeholders ?. With this PR the SQL statement is used as a cache key preventing prepare from being called. Allowing already prepared statements to be run directly. Reducing the amount of round trips. It is not allowed to run SELECT statements in statement.runBatch. Therefor it is not possible to use the event loop as an arguments collection mechanism to further reduce network overhead. As the HANA connection is (currently) only capable of having a single packed in flight there is no possibility that performance will be worsened by having statement executions be queued on the cached prepared statement.

There is a special case for streaming queries (incl. blob streams for @sap/hana-client). It is not possible to determine when the prepared statement is no longer required. Therefor the prepared statements for streaming queries are detached from the cache once initiated.

[BobdenOs]

Do not merge until all tests are passing:
reading a stream commits on end + hdb => Packet size limit exceeded

The root cause of the "random" packet size limit errors. Is caused by the tx.set happening right before the stmt.exec when re using already prepared statements of previous transactions.
potential fix: SAP/node-hdb#293

[kasimos]

This will also try to store the preparations for any call statements, right? When trying out a different way to deal with that, we encountered issues with that, as some built-in procedures like setting application locks will only be executable once.
So one way would be to add the procedure calls with unique key (which I did with adding a comment that the sql preprocessor should ideally strip off before passing it to the plan cache, but no guarantees that it will...) or by adding them with a random uuid or the size of the Map as key, that would anyhow not be a valid sql and therefore shouldn't clash.

[BobdenOs]

Good to know that there are these special procedure. There are similar problems with queries that want to stream their results. They would block the prepared statement for an extended period of time. Therefor in this PR I had added the ability to "detach" a prepared statement (code). Which means that the CALL logic simply has to set the flag to true and it will get its own prepared statement.