Giving the shared catalogues a defined encoding

Hello hackers,

Here's a WIP patch that started on a bugs thread[1].

Problem #1: You can have two databases with different encodings, and
they both pretend that pg_database, pg_authid, pg_db_role_setting etc
are in the local database encoding. That doesn't work too well:
non-ASCII text can be reinterpreted in the wrong encoding.

There's no problem if you only use one encoding everywhere (probably
UTF8). There's also no problem if you use multiple database
encodings, but put only ASCII in the shared catalogues (because ASCII
is a subset of every supported server encoding). This patch is about
formalising and enforcing those two working arrangements, hopefully
invisibly to most users. There's still an escape hatch mode if you
need it, e.g. for a non-conforming pg_upgrade'd system.

The patch invents a new setting CLUSTER CATALOG ENCODING, which can be
inspected with SHOW and changed with ALTER SYSTEM. It has three
possible values:

DATABASE: The shared catalogs use the same encoding as this database,
and all databases in this cluster, and all databases have to use the
default encoding configured at initdb time. Database names and roles
names are free to use any characters you like in that one single
encoding. This is the default.

ASCII: The shared catalogs are restricted to 7-bit ASCII, but in
exchange, databases with different encodings are allowed to co-exist.

UNDEFINED: The old behavior, no restrictions.

There's some documentation in the patch to explain that again in more
words, and a regression transcript showing the behaviour, ie things
you can and can't do in each mode, and how the transitions between
modes can be blocked until you make certain changes.

Problem #2: When dealing with new connections, we currently have
trouble with non-ASCII database and role names because the encoding is
undefined for both the catalogue and the network message. With this
patch, at least the catalogue encoding is defined (unless UNDEFINED),
so there's a pathway to straighten that out.

I am open to better terminology, models, etc. The command seems
verbose, but I hope you'd almost never need to run it, so being clear
seemed better than being brief. I had just CATALOG ENCODING in the
previous version, but then it's not clear that it only affects a few
special catalogues (pg_class et al are always in database encoding, as
they're not shared). I tried SHARED CATALOG ENCODING, but that's
not really a SQL word or concept. CLUSTER is, so here I'm trying
that. On the other hand CLUSTER is a bit overloaded. I had explicit
encoding names eg SET ... TO UTF8 in the previous version, but it
seems easier to call it DATABASE encoding given it had to match the
database anyway if not ASCII/UNDEFINED... There could be other ways
to express all this, though. It does still store the real encoding in
the control file, UTF8 -> 6 or whatever, in case that is useful. When
I was using real encoding names in the syntax, I also had SQL_ASCII
for ASCII mode, but that was quite confusing because SQL_ASCII is well
documented as accepting anything at all, whereas here we need 7-bit
ASCII.

Feedback welcome.

[1] https://www.postgresql.org/message-id/flat/CA%2BhUKGKKNAc599Vp7kFAnLE1%3DV%3DceYujz_YQoSNrvNFGaJ6i7w%40mail.gmail.com#dfb55ce46ace161d81d60c44229e7c80