Rethinking behavior of force_parallel_mode = regress

As of HEAD it is possible to get through all of our regression tests
with these settings:

alter system set force_parallel_mode = regress;
alter system set max_parallel_workers_per_gather = 2;
alter system set parallel_tuple_cost = 0;
alter system set parallel_setup_cost = 0;
alter system set min_parallel_relation_size = 0;

although there are quite a number of cosmetic differences in the outputs
for the core regression tests. (Curiously, contrib, pl, and isolation
seem to pass without any diffs.) In view of the number of bugs we've been
able to identify with this setup, it would be nice to reduce the volume of
the cosmetic differences to make it easier to review the diffs by hand.
I'm not sure there's much that can be done about the row-ordering diffs;
some randomness in the output order from a parallel seqscan seems
inevitable. But we could tamp down the EXPLAIN output differences, which
are much harder to review anyway.

With that thought in mind, I propose that the behavior of
force_parallel_mode = regress is ill-designed so far as EXPLAIN is
concerned. What it ought to do is suppress *all* Gathers from the output,
not just ones that were added in response to force_parallel_mode itself.

I experimented with the attached prototype patch and found that it indeed
greatly reduces the volume of EXPLAIN differences, though it doesn't
remove them all. I did not for example try to hide the effects of partial
aggregation.

If we were to do this, we could remove the Gather.invisible plan node
field altogether, which would be good cleanup in my book.

Even if we don't do this, my code review showed that there's a bug in
what ExplainPrintPlan is doing right now for the case: it neglects to
run InstrEndLoop on the topmost node, which at the very least risks
confusing auto_explain.

Thoughts?

regards, tom lane