Docs: Encourage strong server verification with SCRAM

Hi all,

As touched on in past threads, our SCRAM implementation is slightly
nonstandard and doesn't always protect the entirety of the
authentication handshake:

- the username in the startup packet is not covered by the SCRAM
crypto and can be tampered with if channel binding is not in effect,
or by an attacker holding only the server's key

- low iteration counts accepted by the client make it easier than it
probably should be for a MITM to brute-force passwords (note that
PG16's scram_iterations GUC, being server-side, does not mitigate
this)

- by default, a SCRAM exchange can be exited by the server prior to
sending its verifier, skipping the client's server authentication step
(this is mitigated by requiring channel binding, and PG16 adds
require_auth=scram-sha-256 to help as well)

These aren't currently considered security vulnerabilities, but it'd
be good for the documentation to call them out, considering mutual
authentication is one of the design goals of the SCRAM RFC. (I'd also
like to shore up these problems, eventually, to make SCRAM-based
mutual authn viable with Postgres. But that work has stalled a bit on
my end.)

Here's a patch to explicitly warn people away from SCRAM as a form of
server authentication, and nudge them towards a combination with
verified TLS or gssenc. I've tried to keep the text version-agnostic,
to make a potential backport easier. Is this a good place for the
warning to go? Should I call out that GSS can't use channel binding,
or promote the use of TLS versus GSS for SCRAM, or just keep it
simple?

Thanks,
--Jacob