[PostgreSQL Connector] Remove hard coded proto_version=1 for different PostgreSQL versions [DBZ-8996]

Migrated from [DBZ-8996](https://issues.redhat.com/browse/DBZ-8996)

In order to make your issue reports as actionable as possible, please provide the following information, depending on the issue type.
h1. Bug report

For bug reports, provide this information, please:
h2. What Debezium connector do you use and what version?

PostgreSQL version 3.1
h2. What is the connector configuration?

Is arbitrary but the most import setting were

plugin.name=pgoutput

slot.stream.params=proto_version=4;messages=true
h2. What is the captured database version and mode of deployment?

(E.g. on-premises, with a specific cloud provider, etc.)

Local setup, rancher with stackgres deployed version 16 PostgreSQL database.

Azure, azure flexible server PostgreSQL deployment.
h2. What behavior do you expect?

On slot creation:

`CREATE_REPLICATION_SLOT "debezium" LOGICAL XXX/XXX ( "proto_version" "4", "messages" "true")`
h2. What behavior do you see?

On slot creation:
`CREATE_REPLICATION_SLOT "debezium" LOGICAL XXX/XXX ( "proto_version" "1", "messages" "true")`
h2. Do you see the same behaviour using the latest released Debezium version?

(Ideally, also verify with latest Alpha/Beta/CR version)

Yes, the source of this hardcoding is defined [here.|https://github.com/debezium/debezium/blob/d72944513b2b95d1f9075c5a94c342627dede729/debezium-connector-postgres/src/main/java/io/debezium/connector/postgresql/connection/pgoutput/PgOutputMessageDecoder.java#L232]
h2. Do you have the connector logs, ideally from start till finish?

(You might be asked later to provide [DEBUG/TRACE|https://debezium.io/documentation/reference/stable/operations/logging.html] level log)

h2. How to reproduce the issue using our [tutorial|https://github.com/debezium/debezium-examples/tree/main/tutorial] deployment?

Simply add connector configuration setting slot.stream.params=proto_version=4.
h1. Feature request or enhancement

For feature requests or enhancements, provide this information, please:
h2. Which use case/requirement will be addressed by the proposed feature?

This could help to support heartbeats without using a heartbeat table on a read replica. The situation this would help to address is one where you wish to replicate from a read replica with many databases with varying degrees of activity on them. In order to help keep the slots in check (i.e. prevent growth) it would be convenient to execute:
{code:sql}
SELECT pg_logical_emit_message(false, 'heartbeat', now()::varchar);
{code}
against a primary and have these messages propagate through to the slot.
h2. Implementation ideas (optional)

A starting point could be to identify a PostgreSQL version using:

{code:sql}
SELECT version();
{code}
Using this and [postgresql documentation|https://www.postgresql.org/docs/current/protocol-logical-replication.html#PROTOCOL-LOGICAL-REPLICATION-PARAMS] one could potentially introduce a switch case for postgres versions.