Port to 12.

Notable/non-trivial issues:
 - Dealing with new tableam and abstracted slots while supporting 9.5 is quite
   hairy. Probably deserves some refactoring.
 - nodeModifyTable decides to convert received from PartitionFilter tuple, if
   its tts_ops is not one native of table's am (BufferHeapTupleTableSlot,
   essentially). That might sound sane, but nodeModifyTable doesn't know anything
   about our parent->child attr mapping and has only parent's tupledesc. Thus
   we end up with tupledesc not matching actual tuple. To prevent that,
   always create BufferHeapTupleTableSlot, which (fortunately and weirdly) can
   easily store virtual tuple as well as materialized one.
   (vanilla partitioning does mapping *after* making sure tts_ops is ok)
 - For some reason which is not clear to me, nodeCustom promises that its
   tts_ops is fixed TTSOpsVirtual. RuntimeAppend doesn't think so, however.
   It easily passed BufferHeapTupleSlot up there is no projection, which
   is fine. That's changed by converting to slot to virtual one even in this
   case to keep the promise.
 - append_rte_to_estate: for efficiency 12 introduced
   estate->es_range_table_array mirroring es_range_table. Further, relcache
   management in executor was centralized, and now rri's relcache entries get
   into es_relations, where ExecEndPlan finds them to close. So we also fill
   both arrays.
 - Something like core's 4b40e4: now hashtext wants to know collation. We
   never recorded it, so just pass default one.
 - Two things led to massive duplication of test outputs:
   - Append nodes with single subplan are eliminated now.
   - CTEs are no longer optimization fences by default.

Author: arssher

expected/pathman_array_qual.out

@@ -1,3 +1,7 @@
+/*
+ * Since 8edd0e794 (>= 12) Append nodes with single subplan are eliminated,
+ * causing different output.
+ */
 \set VERBOSITY terse
 SET search_path = 'public';
 CREATE EXTENSION pg_pathman;