sql: prepared statements follow-ups

• Provide more sophisticated test cases covering multiple session interaction scenarios.

• Copy VDBE for each session before execution. Now there's one object in the cache and if it is busy at the moment (i.e. it is executed by another session), execution of prepared statement results in prepare-and-execute procedure. It means that performance benefits from prepared statement may be neglected for statements accessed by several sessions.

• Now after any DDL operation all prepared statements are considered to be expired (at the moment of statement preparation, schema version is saved within prepared statement object; then it is simply checked before execution with current one). Even if prepared statement has no references to changed by DDL operation entity. We need to invalidate only prepared statements related to the subject of DDL operation.

• Provide an opportunity to specify types of parameters in :prepare() interface and check them before execution of prepared statement. Now type of binding parameters is always assumed to be ANY.

Start by tracing the :prepare() interface, the prepared-statement cache, VDBE execution, and schema-version invalidation described in the issue; review how multiple sessions interact. Done means the listed session tests, per-session VDBE handling, targeted DDL invalidation, and parameter-type checks are all implemented and verified.