Progress reporting: a debug trace and a test framework

The two patches attached add a debug trace and a test framework for
progress reporting. They were first posted in [1]; they get their own
thread now, as Michael suggested.

0001 adds PROGRESS_DEBUG. With it defined, every change to a backend's
progress state is logged at LOG_SERVER_ONLY, so a test can read back the
exact sequence of reports a command makes, without needing concurrency or
injection points. It is compiled out by default: with it undefined the
object code of backend_progress.c is unchanged (the same instruction
stream, only the line numbers baked into existing elog calls shift), and
the test below skips, so "make check" and "meson test" are not any slower.

0002 adds the test module test_progress. It replays each backend's trace
and checks the rules that hold for every command -- values continue from
the last one logged, counters do not decrease or only go back to 0, done
counters stay within their totals, phases take defined values, and a
command writes only its own parameters -- and then the exact succession of
phases for each command. It also checks every parameter of
commands/progress.h against a description, on any build, so a new or
renumbered parameter has to be described before the test passes.

These checks have already been useful: the trace is what found the three
blips fixed in 3be29d9346d, and the description check flagged, while
rebasing, that 1378aa13430 had added PROGRESS_VACUUM_CURRENT_INDEX_RELID
without describing it.

Run on master, the framework also flags two harmless blips that no view
exposes: when one command builds or vacuums several indexes in a row
(REPACK, VACUUM FULL, VACUUM in several cycles), the index-build tuple
counter and the dead-item counters step straight to the next round's
value instead of first going back to 0. The test sets these aside as
known-accepted (listed in @ACCEPTED, the dead-item one under a TODO) so
the suite is green; they are harmless and I have left the behavior as it
is. Resetting the counters in every build and cycle removes them and
makes the dead-item counters match their documented "collected since the
last cycle" meaning; I can post that as a small optional follow-up if it
is wanted.

[1] https://postgr.es/m/179018818545.3031865.5809261654654798774@gmail.com