pgsql: Reimplement planner's handling of MIN/MAX aggregate optimization

Reimplement planner's handling of MIN/MAX aggregate optimization (again).

Instead of playing cute games with pathkeys, just build a direct
representation of the intended sub-select, and feed it through
query_planner to get a Path for the index access.  This is a bit slower
than 9.1's previous method, since we'll duplicate most of the overhead of
query_planner; but since the whole optimization only applies to rather
simple single-table queries, that probably won't be much of a problem in
practice.  The advantage is that we get to do the right thing when there's
a partial index that needs the implicit IS NOT NULL clause to be usable.
Also, although this makes planagg.c be a bit more closely tied to the
ordering of operations in grouping_planner, we can get rid of some coupling
to lower-level parts of the planner.  Per complaint from Marti Raudsepp.

Branch
------
master

Details
-------
http://git.postgresql.org/pg/commitdiff/8df08c84894001d3d3f5d10b3290a1063a453316

Modified Files
--------------
src/backend/nodes/copyfuncs.c            |   19 -
src/backend/nodes/equalfuncs.c           |   14 -
src/backend/nodes/outfuncs.c             |    5 +-
src/backend/optimizer/path/indxpath.c    |   14 +-
src/backend/optimizer/path/pathkeys.c    |   96 +-----
src/backend/optimizer/plan/planagg.c     |  585 +++++++++++-------------------
src/backend/optimizer/plan/planmain.c    |    9 -
src/backend/optimizer/plan/planner.c     |    5 +-
src/include/nodes/relation.h             |    8 +-
src/include/optimizer/paths.h            |   16 -
src/test/regress/expected/aggregates.out |   30 +-
src/test/regress/sql/aggregates.sql      |    7 +-
12 files changed, 263 insertions(+), 545 deletions(-)