Restructuring Paths to allow per-Path targetlist info

Although it may not be obvious to the naked eye, I have been working away
on that long-overdue upper-planner pathification project. One thing
that's necessary to make that happen is to keep track of the targetlists
of upper plan levels within the Path data structures, since once you get
past the scan/join phase you need to know explicitly what each level of
plan is actually going to compute. I'd been trying to add such info only
to the new types of Path, but that wasn't proving to work very well
notationally, and in any case there's good reason to think that we should
track output tlists explicitly even while considering basic scan/join
paths. (As an example, if we want the planner to take into account the
cost savings from fetching an expensive function value from a functional
index rather than recomputing it from scratch, we really need a way of
denoting which Paths can provide the function value at no extra cost.)

So, the attached patch just bites the bullet and adds explicit output
tlist information to struct Path. I did set things up so that the cost
is only one pointer in each Path in the typical case where Paths emit
the set of Vars needed from their relation; in that case, they just
point to a default PathTarget struct embedded in the parent RelOptInfo.
A Path emitting something else will need its own PathTarget struct.
(Since this patch is just trying to change the notation around, there
aren't actually any cases yet of a Path with its own PathTarget.)

I did take the time to improve the cost accounting for PlaceHolderVars;
before, we sometimes overcharged substantially for those (by counting
their eval costs at multiple plan levels) and sometimes undercharged
for them (by not counting them at all). It's not perfect yet, cf the
new comments in add_placeholders_to_joinrel(), but it's a lot better
than before. This change results in a couple of minor regression test
changes because the planner changes join order now that it realizes that
sub-selects inside PlaceHolderVars aren't free ;-).

Barring objections, I'd like to push this soon.

regards, tom lane