Post-mortem: Another bug in pg_operator.h

OK, I have done the deed.  If I blew it, you can back out the last
few commits and then come break my fingers ... but I believe it's
right.

What I found was a boatload of minor typos in operator definitions
for lesser-used types.  (My faith in the analysis procedure is
strengthened by the fact that it didn't gripe about any operators
for the thoroughly-shaken-out types like int4 and float8.)  The
operators I had to change were for these types and combinations:int8int4 vs. int8, and vice versaint2 vs. int4, and
viceversabool < bool, bool > booltintervalpathpath vs. pointbox vs. pointfloat4 vs. float8, and vice versacircle vs.
pointlseg

A typical bug is "int48le claims to be the commutator of int48ge,
but it ought to commute with int84ge".  I also saw a lot of confusion
between the commutator and negator roles ... we could do with some
better documentation, I suspect.

The only regression test that changed results was tinterval, which
I already knew was broken.  This says that the coverage of our
regression tests for off-the-beaten-path datatypes is not thorough :-(

Most of the checks I used to find bogus entries are embodied in 
the new regression test opr_sanity --- you can look at that script
to see whether you agree with the conditions I checked.

One thing I'm still a little bothered by is that I don't understand
the difference between the oprlsortop and oprrsortop columns.  In
all the existing tuples that weren't demonstrably bogus, the two
columns have the same value.  What's the point of distinguishing
them, and do the conditions expressed in opr_sanity need refinement?

Note that these changes require an initdb to be effective.  Worse,
there's still one initdb-forcing change to come, namely resolving
which operator really is point @ path.  The opr_sanity regression
test will keep failing until we fix this ;-).  So, the geometric
operator gurus had better get together and decide which it should
be, pronto.
        regards, tom lane