feat: SCRAM-SHA-256 encode role passwords operator-side (#10724)

Before emitting `CREATE`/`ALTER ROLE ... PASSWORD '...'`, the operator
now SCRAM-SHA-256 encodes any cleartext password operator-side
(client-side from PostgreSQL's point of view). The literal PostgreSQL
parses (and that extensions such as `pg_stat_statements` or `pgaudit`
may capture) is the SCRAM verifier ultimately stored in
`pg_authid.rolpassword`, never the cleartext secret. This matches what
`psql \password` and libpq's `PQencryptPasswordConn` do, and applies to
every basic-auth Secret the operator consumes: the `postgres` superuser,
the application user, and managed-role password secrets. The existing
statement-log suppression for CREATE/ALTER ROLE remains in effect.

Passwords already supplied to PostgreSQL in its MD5 or SCRAM-SHA-256
shadow form are forwarded unchanged, so users who store a pre-hashed
value in the Secret retain full control over the stored hash.

Opt-out: set the annotation `cnpg.io/passwordPassthrough: "enabled"` on
the basic-auth Secret to have the operator forward the password literal
verbatim and let PostgreSQL encode it according to its own
`password_encryption` GUC. The opt-out is per-Secret, so a single
cluster can mix passthrough and operator-encoded secrets freely,
restoring the pre-change behaviour for clusters that explicitly run with
`password_encryption = md5` or otherwise need PostgreSQL to choose the
hash format.

Signed-off-by: Leonardo Cecchi <leonardo.cecchi@enterprisedb.com>
Signed-off-by: Armando Ruocco <armando.ruocco@enterprisedb.com>
Signed-off-by: Gabriele Bartolini <gabriele.bartolini@enterprisedb.com>
Signed-off-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
Co-authored-by: Armando Ruocco <armando.ruocco@enterprisedb.com>
Co-authored-by: Jaime Silvela <jaime.silvela@mailfence.com>
Co-authored-by: Gabriele Bartolini <gabriele.bartolini@enterprisedb.com>
Co-authored-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>