preliminary: logical column order

This patch provides a preliminary implementation of the logical column
ordering functionality recently proposed on -hackers. This patch has a
number of known issues, so please don't apply it.

Current functionality implemented:

        - Added attpos to the system catalogs & bumped the catalog
          version: initdb required
        - COPY TO/FROM obey logical column ordering
        - When expanding "SELECT * ...", we make sure to obey logical
          column order (see below, however)
        - If INSERT is given an empty column list, it will produce the
          necessary implicit column list in sorted by attpos
        - (unrelated) improve a bunch of comments in pg_class.h,
          remove some dead code from pg_attribute.h, refactor some
          code in access/common/printtup.c

Remaining work to do:

        - Change the name of the pg_attribute attribute to something
          other than 'attpos', per the discussion on -hackers. I don't
          believe we've settled on the right name yet.
        - The code for actually sorting the columns in attpos-order is
          duplicated a few times -- this was just done for the sake of
          convenience, I'm going to clean this up and stick it in a
          single, shared location in the new patch.
        - The INSERT change causes the alter_table regression tests to
          fail (the regression.diff) is attached. This appears to be
          the logical column ordering interacting with inheritance,
          but I haven't yet taken an in-depth look at it.
        - When processing a "SELECT *", for example, the actual data
          columns are returned in the right order, but the
          RowDescription messages sent by libpq are not (i.e. they are
          sent in attnum-order, not attpos).

          In SendRowDescriptionMessage() and related printtup code, I
          took a look at trying to sort the attributes we're about to
          send RowDescription messages for by their 'attpos', but the
          TupleDesc that we have for the return type doesn't included
          a filled-in attpos.

          I spent a while trying to see how feasible it would be to
          fill in the result-type-TupleDesc with an attpos where
          available, but couldn't figure out an easy way to do
          this. Are there any suggestions on how this should be best
          done?
        - I haven't yet implemented ordering-by-attpos for the output
          columns of a join, or the alias->column matching in the FROM
          alias list (per Tom's email to -hackers). I saw a couple
          places where I might be able to do this, but I'm quite sure
          what the correct spot is. Tom, do you have any suggestions?

Any comments would be gratefully appreciated.

-Neil