Test that cat_tools still works after a binary pg_upgrade (not just that extversion carried over)

[jnasbyupgrade]

Problem

We do not verify that cat_tools still works after a binary pg_upgrade of a
cluster that has the extension installed — only that its version number carried
over.

The CI pg-upgrade-test job installs cat_tools on an old cluster, CREATE EXTENSION, binary-pg_upgrades to a newer major, then:

• "Verify extension version after upgrade" — checks only extversion on the
  upgraded database.
• "Run test suite on upgraded cluster" (make test) — pg_regress creates a
  fresh regression database and does CREATE EXTENSION there, so it tests a
  fresh install on the new PostgreSQL, NOT the binary-migrated extension
  objects carried over by pg_upgrade.

So the actual pg_upgraded extension (functions, views, types as physically
migrated) is never exercised on the new version. A relkind/OID/catalog
representation that survives ALTER EXTENSION UPDATE could still misbehave after
a binary pg_upgrade (different mechanism: raw catalog migration, not re-running
install SQL).

What to add

After binary pg_upgrade, run the pgTAP suite (or a meaningful subset)
against the database that was upgraded (the one with the pre-existing,
carried-over extension) — not a fresh regression DB — and assert the functions
behave correctly on the new PostgreSQL version.

Distinct from existing issues

• Not Testing: verify ALTER EXTENSION UPDATE yields a DB equivalent to a fresh install #23/Testing: verify ALTER EXTENSION UPDATE yields a DB equivalent to a fresh install #24 (extension ALTER EXTENSION UPDATE equivalence — implemented in
  PR Add new functions, enums #16 via TEST_LOAD_SOURCE=upgrade).
• Not Add upgrade-drift test: detect schema drift between fresh install and sequential updates #20 (fresh-vs-sequential-update schema drift).
  This is about binary pg_upgrade of the whole cluster with the extension
  installed.