Improves lock contention when multiple parallel read-queries are being executed

[jprafael]

Context
Using duckdb-sqllite as the metadata catalog for ducklake.
When running multiple read-only queries in parallel (using .cursor()) the code runs into lock contention and has worse performance than single threaded.

Hotspot 1

• In SqliteInitInternal invokes sqlite Prepare for each query, even in the common case where the sql is exactly the same as before (next iteration with different rowid filters).
• This version caches the prepared statement and reuses it if its the same as before.
• Q for maintainers: can it be assumed that the statement that is prepared is always the same (e.g. same bind_data/column_ids)? if so we can skip the equality check after the prepared statement is cached.

Hotspot 2

• In SqliteParallelStateNext the code holds the gstate.lock while running SqliteInitInternal.
• This version mutates the global state while holding the lock, but releases it before running SqliteInitInternal

This leads to a ~10x speedup in my environment (16x threads)

[staticlibs]

Thanks!