pgsql: Add child_append_relid_sets to ElidedNode; use in pg_plan_advice

Add child_append_relid_sets to ElidedNode; use in pg_plan_advice.

Commit 0d4391b265f83023d0b7eed71817517410f76e60 taught the planner
to store information about the RTIs of SubqueryScan, Append, and
MergeAppend node elided from the plan using a new ElidedNode data
structure; an hour later, 7358abcc6076f4b2530d10126ab379f8aea612a5
taught to save the RTIs of an Append node into another Append
node using a new child_append_relid_sets field. Regrettably,
despite the fact that both commits were written by me and the
fact that both were part of the same patch set, the latter commit
failed to deal with the case where an Append node first acquires
child_append_relid_sets != NIL and then gets elided. I believe that
I thought that was impossible, but the included test case shows that
it isn't.

The proper fix involves updating the definition of ElidedNode to
carry child_append_relid_sets, so this commit does that, breaking
ABI compatibility. That's fine for the master branch, but it's a
bit unfortunate to be doing do that so close to the planned ship
date for v19. However, shipping v19 without fixing this appears
(at least to me) to be even more unfortunate.

Backpatch-through: 19
Discussion: http://postgr.es/m/CA+TgmoYYHC4i-Gpzc9-JYHqih6pOK+6LTYFiNR-PioXG1nKkOQ@mail.gmail.com

Branch
------
master

Details
-------
https://git.postgresql.org/pg/commitdiff/38475f23c83358eafe42a410e4342eb8d64ba24c

Modified Files
--------------
contrib/pg_overexplain/expected/pg_overexplain.out | 9 ++++++---
contrib/pg_overexplain/pg_overexplain.c | 3 +++
contrib/pg_plan_advice/expected/partitionwise.out | 13 +++++++++++++
contrib/pg_plan_advice/pgpa_scan.c | 3 +++
contrib/pg_plan_advice/sql/partitionwise.sql | 4 ++++
src/backend/optimizer/plan/setrefs.c | 18 +++++++++++++-----
src/include/nodes/plannodes.h | 4 ++++
7 files changed, 46 insertions(+), 8 deletions(-)