pgsql: Clean up a couple of ad-hoc computations of the maximum number of

Log Message:
-----------
Clean up a couple of ad-hoc computations of the maximum number of tuples
on a page, as suggested by ITAGAKI Takahiro.  Also, change a few places
that were using some other estimates of max-items-per-page to consistently
use MaxOffsetNumber.  This is conservatively large --- we could have used
the new MaxHeapTuplesPerPage macro, or a similar one for index tuples ---
but those places are simply declaring a fixed-size buffer and assuming it
will work, rather than actively testing for overrun.  It seems safer to
size these buffers in a way that can't overflow even if the page is
corrupt.

Modified Files:
--------------
    pgsql/src/backend/access/gist:
        gistvacuum.c (r1.6 -> r1.7)
        (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/gist/gistvacuum.c.diff?r1=1.6&r2=1.7)
    pgsql/src/backend/access/nbtree:
        nbtree.c (r1.130 -> r1.131)
        (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/nbtree/nbtree.c.diff?r1=1.130&r2=1.131)
    pgsql/src/backend/commands:
        vacuum.c (r1.313 -> r1.314)
        (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/commands/vacuum.c.diff?r1=1.313&r2=1.314)
        vacuumlazy.c (r1.57 -> r1.58)
        (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/commands/vacuumlazy.c.diff?r1=1.57&r2=1.58)
    pgsql/src/backend/nodes:
        tidbitmap.c (r1.6 -> r1.7)
        (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/nodes/tidbitmap.c.diff?r1=1.6&r2=1.7)
    pgsql/src/include/access:
        htup.h (r1.76 -> r1.77)
        (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/include/access/htup.h.diff?r1=1.76&r2=1.77)