Decoupling our alignment assumptions about int64 and double

Over in the long-running thread about resurrecting AIX support,
one salient concern is that AIX has alignof(int64) = 8 but
alignof(double) = 4. This breaks all our code that supposes
that ALIGNOF_DOUBLE is the platform's maximum alignment spec.
We had coped with this via various unspeakable klugery back
when AIX was considered supported, but nobody wants to put
back those restrictions if we re-support AIX. (See my gripe
at [1], but I believe Heikki and Andres complained of this
in more detail long ago.)

Here is a modest proposal for fixing that in a clean way.
Let's break TYPALIGN_DOUBLE into three values, TYPALIGN_DOUBLE
for float8 only, TYPALIGN_INT64 for 64-bit integral types
including pointers, and TYPALIGN_MAX to represent MAXALIGN
alignment regardless of which of the first two determine it.
We need TYPALIGN_MAX because that's the value composite
types should use, so that their alignment doesn't change
if somebody adds or deletes a column of a relevant type.
Given that design, the patch is pretty straightforward,
and smaller than I feared it might be. (Though I might
have missed a spot or two.)

I think this is good cleanup and deserves consideration
whether we accept the AIX patch soon or not.

A loose end that deserves mention is that I noticed we
are very inconsistent about the length/alignment
attributed to polymorphic types:

select typname, typlen, typalign from pg_type where typname like 'any%';
typname | typlen | typalign
-------------------------+--------+----------
any | 4 | i
anyarray | -1 | m
anycompatible | 4 | i
anycompatiblearray | -1 | m
anycompatiblemultirange | -1 | m
anycompatiblenonarray | 4 | i
anycompatiblerange | -1 | m
anyelement | 4 | i
anyenum | 4 | i
anymultirange | -1 | m
anynonarray | 4 | i
anyrange | -1 | m
(12 rows)

(Previous to this patch, the 'm' entries were 'd'.)

In one sense this doesn't really matter, since no actual
value should have any of these types attributed to it;
but it annoys me that they're not all alike. I'm tempted to
make them all 4/'i' which seems to be the older convention.

A more aggressive answer would be to change these to some
actually-illegal values, in hopes of catching anyplace where
we did try to rely on the values. But that seems like
material for a different patch.

regards, tom lane

[1] https://www.postgresql.org/message-id/581905.1769550155%40sss.pgh.pa.us