DROP relation IF EXISTS Docs and Tests - Bug Fix

This is a follow-up to Bug # 16492 which also links to a thread sent to
-hackers back in 2018.

I'm firmly of the belief that the existing behavior of DROP relation IF
EXISTS is flawed - it should not be an error if there is a namespace
collision but the relkind of the existing relation doesn't match the
relkind set by the DROP command.

Since our documentation fails to elaborate on any additional behavior, and
uses the relkind in the description, our users (few as they may be) are
rightly calling this a bug. I loosely believe that any behavior change in
this area should not be back-patched thus for released versions this is a
documentation bug. I have attached a patch to fix that bug.

In putting together the patch I noticed that the existing drop_if_exists
regression tests exercise the DROP DOMAIN command. Out of curiosity I
included that in my namespace testing and discovered that DROP DOMAIN
thinks of itself as being a relation for purposes of IF EXISTS but DROP
TABLE does not. I modified both DROP DOMAIN and the Glossary in response
to this finding - though I suspect to find disagreement with my choice. I
looked at pg_class for some guidance but a quick search for RELKIND_
(DOMAIN) and finding nothing decided I didn't know enough and figured to
punt on any further exploration of this inconsistency.

The documentation and tests need to go in and be back-patched. After that
happens I'll see whether and/or how to go about trying to get my PoV on the
behavioral change committed.

David J.