WIP: splitting EquivalenceClasses out from PathKeys

Attached is a snapshot of what I've been working on for the past week.
This patch refactors the existing "pathkeys" data structure to create
a separate, explicit notion of equivalence classes of variables.
It's not ready to commit yet but I'm pretty pleased with the way it's
coming out: several ugly, ad-hoc chunks of code have gone away in favor
of something that seems much clearer. Some of the improvements:

* Instead of generating all possible equalities from an equivalence set
and then throwing away redundant ones, we now generate only the ones
we actually want. Should be faster, though I've not tried to do any
benchmarking.

* Derived equalities now use operators that are correctly determined
from operator family information, instead of assuming they're named
"=". (This is really fallout from the previous opfamily patch.)

* No longer have to fail if a particular cross-type equality operator
isn't available. (We back up and just use the original clauses,
instead; also, because we don't insist on generating every possible
deduction, there are many cases where we need not fail at all though
the old code did.)

* Works with equivalence clauses found below outer joins, whereas the
old code couldn't deduce anything from them.

* Vastly better way of detecting irrelevant pathkeys. My old patch
http://archives.postgresql.org/pgsql-committers/2005-06/msg00160.php
is entirely reverted. The new code handles that and also works at the
mergejoin level; for instance Greg Mitchell's recent complaint is fixed:
http://archives.postgresql.org/pgsql-hackers/2006-11/msg00625.php

The main thing left to do is rework the code for selecting mergejoin
clauses (it's just band-aided at the moment). I haven't thought hard
yet about how that should be done, but almost anything would be an
improvement on the way it's been done so far ;-). I'm also aware of
one open bug: the planner seems to have forgotten how to generate
inner-indexscan plans for inheritance sets. I haven't dug into that in
detail but I imagine I'm missing some code to adjust the equivalence
classes when a child relation is added to the query.

Comments?

regards, tom lane