future-proofing relkind tests, take two

Here's another attempt to reduce the number of places in the code that
need to be updated when adding a new relkind. It adds a few macros --
RELKIND_HAS_STORAGE(), RELKIND_HAS_SYSTEM_ATTS(), and
RELKIND_HAS_SYSTEM_GENERATED_ATTNAMES() and uses them in place of more
ad-hoc tests for the same conditions -- and it rewords a few
problematic messages (some of which are already slightly inaccurate)
so that they won't need updating when we add a new relkind for foreign
tables.

Thoughts? This is not a complete solution by any means, but I don't
think it makes anything worse (unless you hate the proposed wording, I
suppose) and it has the added benefit of simplifying the code in a few
places.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company