LWLock tranches registered by SLRUs are thrown away at startup

Greetings,

When an SLRU leaves its tranche IDs at 0, shmem_slru_init() registers
tranches for it at startup. LWLockShmemInit() runs a moment later and
resets the tranche count, so those tranches are forgotten. Nothing
looks wrong at first, because every backend inherits the postmaster's
count. But the next tranche anyone registers is handed the SLRU's ID
and takes over its name. From then on, the SLRU's locks show up under
that name in pg_stat_activity and the trace probes, and looking up the
SLRU's other tranche can fail with "tranche N is not registered".

Once such an SLRU exists, any preloaded library that registers a tranche
is enough to trigger it. No builtin SLRU leaves its IDs at 0, so
nothing shipping hits this yet. That is the only way an extension can
define an SLRU, though, so the first extension that does will hit it.
This came in with 2e0943a8597 and is in REL_19_STABLE.

The attached patch adds a test that registers one more tranche and
checks the names. Without the lwlock.c change, it fails on Linux and
Windows with:

ERROR: tranche 102 is not registered

I ran into this while setting up a TraceLogging (ETW) backend for the
static probes on Windows, which will be a separate patch. Under
EXEC_BACKEND, backends don't inherit the postmaster's count, so with
the LWLock probes on, the first acquisition of one of the SLRU's locks
fails.

The fix initializes the tranche table once, from whichever of
LWLockNewTrancheId() and LWLockShmemInit() gets there first, and never
resets it after that. If you'd rather fix the ordering in shmem.c, I
can rework it that way.

--
Bryan Green
EDB: https://www.enterprisedb.com