Rewrite the code that applies scan/join targets to paths.

 Rewrite the code that applies scan/join targets to paths.
 
 If the toplevel scan/join target list is parallel-safe, postpone
 generating Gather (or Gather Merge) paths until after the toplevel has
 been adjusted to return it.  This (correctly) makes queries with
 expensive functions in the target list more likely to choose a
 parallel plan, since the cost of the plan now reflects the fact that
 the evaluation will happen in the workers rather than the leader.
 The original complaint about this problem was from Jeff Janes.
 
 If the toplevel scan/join relation is partitioned, recursively apply
 the changes to all partitions.  This sometimes allows us to get rid of
 Result nodes, because Append is not projection-capable but its
 children may be.  It also cleans up what appears to be incorrect SRF
 handling from commit e2f1eb0ee30d144628ab523432320f174a2c8966: the old
 code had no knowledge of SRFs for child scan/join rels.
 
 Because we now use create_projection_path() in some cases where we
 formerly used apply_projection_to_path(), this changes the ordering
 of columns in some queries generated by postgres_fdw.  Update
 regression outputs accordingly.
 
 Patch by me, reviewed by Amit Kapila and by Ashutosh Bapat.  Other
 fixes for this problem (substantially different from this version)
 were reviewed by Dilip Kumar, Amit Khandekar, and Marina Polyakova.
 
 Discussion: http://postgr.es/m/CAMkU=1ycXNipvhWuweUVpKuyu6SpNjF=yHWu4c4US5JgVGxtZQ@mail.gmail.com