Our ABI diff infrastructure ignores enum SysCacheIdentifier

I discovered $SUBJECT while working on commits dbb09fd8e et al.
The point of those commits was to back-patch addition of a syscache
that previously existed only in v18+, so naturally I was concerned
about not breaking ABI by changing any existing syscache's ID.
I tested whether abidiff would bleat about it if I intentionally
changed an ID, and found that *it didn't*.

I don't think this is (quite) a bug in libabigail.  They are pretty
clear that what they regard as ABI is:

       ... the descriptions of the types reachable by the interfaces
       (functions and variables) that are visible outside of their
       translation unit.

We do not use enum SysCacheIdentifier as the declared type of any
global variable or any globally-visible function argument or result.
Therefore it's not ABI per their definition.

This is frankly pretty scary.  Now that we know the rules, we can
fix it for enum SysCacheIdentifier, but we have other things that are
similarly vulnerable.  The thing I am most concerned about right now
is enum GUCs.  The guc.c APIs mandate that those be declared as type
int, so I think (haven't actually checked) that most if not all of
the associated enum values will not be perceived as ABI-relevant by
abidiff.  What can we do about that?

As for SysCacheIdentifier, the root of the problem is that
SearchSysCache and friends are declared to take "int cacheId"
not "enum SysCacheIdentifier cacheId".  Likely we should change
that in HEAD, but that'd be an actual not theoretical ABI break
(the enum's not necessarily int-width).  In the back branches
I'm thinking about adding a dummy function just for this purpose,
more or less as in the under-commented patch attached.

Thoughts?

			regards, tom lane