Setup SQL server based on pgx frontend/backend protocol

[k-anshul]

closes #4817

[begelundmuller]

Two overall comments:

1. It's worth going over the PR and refactoring or clarifying use of the word "Postgres". There are many places where it's not clear that the code pertains to Postgres wire compatibility, as opposed to connecting to an external Postgres database. In some cases, a docstring would help, in other cases, it's worth considering using a term like psql or pgwire instead of postgres.
2. The code in runtime/resolvers/postgres_sql.go is pretty hard to navigate, despite the logic being fundamentally pretty simple. I suggest taking a fresh look at the code with a focus on simplifying and documenting the code. There's also a question (raised in one of the below comments) of whether this should even be a resolver, or if it's better implemented in a dedicated package for Postgres wire compatibility.

[begelundmuller]

We only cache for DuckDB, not Druid or ClickHouse. I think running each psql query twice, even if it may lead into DB internal caches is too excessive. If using s.runtime.Resolve, which returns JSON, why can't that just be passed in here? There is risk of a leaked connection then as far as I can tell?

[k-anshul]

During continuous analysis of psql library we have encountered some critical issues in the library:

1. The statement cache and portal cache is at server level instead of connection level which is a deviation from standard protocol and also a probable security issue.
2. The prepared statements never go out of memory even when connection is terminated which can lead to weird memory leaks.
3. Connections are not closed properly on server close.
4. The design is very server centric instead of connection centric.

Also we can simplify our code using pgx pkg and using a connection centric design. I am closing this PR and will raise a follow up that builds on some of the changes done here.