Reducing the range of OIDs consumed by genbki.pl

The attached patch stems from the conversation at [1]/messages/by-id/3737988.1618451008@sss.pgh.pa.us;
I'm starting a new thread to avoid confusing the cfbot.

Briefly, the idea is to allow reverting the change made in
commit ab596105b to increase FirstBootstrapObjectId from
12000 to 13000, by teaching genbki.pl to assign OIDs
independently in each catalog rather than from a single
OID counter. Thus, the OIDs in this range will not be
globally unique anymore, but only unique per-catalog.

The aforesaid commit had to increase FirstBootstrapObjectId
because as of HEAD, genbki.pl needs to consume OIDs up through
12035, overrunning the old limit of 12000. But moving up that
limit seems a bit risky, cf [2]/messages/by-id/CAGPqQf3JYTrTB1E1fu_zOGj+rG_kwTfa3UcUYPfNZL9o1bcYNw@mail.gmail.com. It'd be better if we could
avoid doing that. Since the OIDs in question are spread across
several catalogs, allocating them per-catalog seems to fix the
problem quite effectively. With the attached patch, the ending
OID counters are

GenbkiNextOid(pg_amop) = 10945
GenbkiNextOid(pg_amproc) = 10697
GenbkiNextOid(pg_cast) = 10230
GenbkiNextOid(pg_opclass) = 10164

so we have quite a lot of daylight before we'll ever approach
12000 again.

Per-catalog OID uniqueness shouldn't be a problem here, because
any code that's assuming global uniqueness is broken anyway;
no such guarantee exists after the OID counter has wrapped
around.

So I propose shoehorning this into v14, to avoid shipping a
release where FirstBootstrapObjectId has been bumped up.

regards, tom lane

[1]: /messages/by-id/3737988.1618451008@sss.pgh.pa.us

[2]: /messages/by-id/CAGPqQf3JYTrTB1E1fu_zOGj+rG_kwTfa3UcUYPfNZL9o1bcYNw@mail.gmail.com