CI support should test that the archive produced by `make dist` actually builds

[jnasbyupgrade]

cat_tools just shipped a regression where the entire build was broken for every real
PGXN consumer, but CI stayed green the whole time. The extension added a Makefile
include of a file auto-generated by a git submodule update --init rule. That works
fine from a normal git clone (which is what CI always tests against), but make dist
packages the release via git archive, which strips .git and submodule content
entirely -- so in the actual shipped tarball, that include's rule failed
("fatal: not a git repository"), which aborted the whole Makefile parse, breaking
make, make install, everything. Nobody noticed until someone manually extracted the
built archive into a directory with no .git and ran make by hand.

More generally: any repo built on pgxntool can accumulate a dependency -- a submodule,
a generated file, an environment assumption -- that only works inside a real git
checkout, and nothing in the standard CI wiring exercises the actual dist artifact a
consumer downloads. make dist/make tag already produce that artifact
(git archive of the release tag); the gap is that nothing ever builds from it.

Proposed: as part of pgxntool's own standard CI guidance/support (README, and ideally a
reusable Makefile target or CI snippet consuming repos can drop in), add a check that:

1. Builds the archive the same way make dist does (git archive of HEAD or the tag).
2. Extracts it into a directory with no .git present at all.
3. Runs a plain make and make install there and confirms both succeed.

This would have caught the cat_tools regression immediately, in the same PR that
introduced it, rather than relying on someone manually re-deriving the "no .git"
scenario after the fact. See Postgres-Extensions/cat_tools#80
for the concrete bug and fix this is generalizing from.