REPACK (CONCURRENTLY) rewrites tables marked with user_catalog_table

IIUC this can cause problems for logical replication consumers, since the
CONCURRENTLY path doesn't go through the rewriteheap.c machinery like the
non-concurrent path does:

CREATE TABLE t (a INT PRIMARY KEY, b TEXT) WITH (user_catalog_table = true);
ALTER TABLE t ALTER COLUMN b TYPE varchar(100); -- correctly fails
REPACK (CONCURRENTLY) t; -- should fail but doesn't

I believe the fix for v19 is to add a check for
RelationIsUsedAsCatalogTable() in check_concurrent_repack_requirements()
(plus a corresponding update to the list of CONCURRENTLY limitations in the
docs).

--
nathan