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