Splitting up guc.c

Here's a WIP stab at the project Andres mentioned [1] of splitting up
guc.c into smaller files.  As things stand here, we have:

1. guc.c: the core GUC machinery.
2. guc_tables.c: the data arrays, and some previously-exposed constant
tables.  guc_tables.h can now be considered the associated header.
3. guc_hooks.c: (most of) the per-variable check/assign/show hooks
that had been in guc.c.  guc_hooks.h declares these.

File sizes are like so:

$ wc guc*c
  2629   9372  69467 guc-file.c
  7422  25136 202284 guc.c
   939   2693  22915 guc_hooks.c
  4877  13163 126769 guc_tables.c
 15867  50364 421435 total
$ size guc*o
   text    data     bss     dec     hex filename
  13653       4     112   13769    35c9 guc-file.o
  54953       0     564   55517    d8dd guc.o
   6951       0     112    7063    1b97 guc_hooks.o
  43570   62998     216  106784   1a120 guc_tables.o

I'm fairly happy with the way things turned out in guc.c and
guc_tables.c, but I don't much like guc_hooks.c.  I think instead of
creating such a file, what we should do is to shove most of those
functions into whatever module the GUC variable is associated with.
(Perhaps commands/variable.c could absorb any stragglers that lack
a better home.)  I made a start at that for wal_consistency_checking
and the syslog parameters, but haven't gone further yet.

Before proceeding further, I wanted to ask for comments on a design
choice that might be controversial.  Even though I don't want to
invent guc_hooks.c, I think we *should* invent guc_hooks.h, and
consolidate all the GUC hook function declarations there.  The
point would be to not have to #include guc.h in headers of unrelated
modules.  This is similar to what we've done with utils/fmgrprotos.h,
though the motivation is different.  I already moved a few declarations
from guc.h to there (and in consequence had to adjust #includes in
the modules defining those hooks), but there's a lot more to be done
if we apply that policy across the board.  Does anybody think that's
a bad approach, or have a better one?

BTW, this is more or less orthogonal to my other GUC patch at [2],
although both lead to the conclusion that we need to export
guc_malloc and friends.

            regards, tom lane

[1] https://www.postgresql.org/message-id/20220905233233.jhcu5jqsrtosmgh5%40awork3.anarazel.de
[2] https://www.postgresql.org/message-id/flat/2982579.1662416866%40sss.pgh.pa.us