OpenSystemsDevelopment / qpdf

* Based on feedback, keep gpg as well as cosign for the indefinite
  future
* Streamline release creation process by using the `gh` command-line
  tool (GitHub's official CLI) rather than old-school curl directly
  against the GitHub API, a procedure that predates the `gh` command.

Thanks to qooxzuub for the suggested update.

- Introduce distinct header guards to enable simultaneous inclusion of both headers.
- Update `README-maintainer.md` to document the changes .

…directives across modules to improve clarity and enforce better assertion practices.

Plus sneak in some spell checks

I always think of doing this after I have already tagged the release.

Figuring out which classes are part of the public API by using library
symbols is fragile (dependent on specific compiler optimizations) and
unreliable (misses some inline things). Instead, use castxml, a tool
that parses C++ to an abstract syntax tree and generates XML, to get a
reliable accounting of public classes and their sizes.

This requires a special build option.

Add a CI job to test qpdf with other than the default zlib
implementation. This incldues a check that the new zlib really is not
the default, so the new test will fail if the default because zlib-ng.

Also remove trailing whitespace

This is how I work with the file, so this format is most convenient
for me.

Build in the order that is most likely to detect failures earlier.

The official, signed AppImage will be build locally for now for
security of my key, but I still want it to be built in a clean,
controlled environment based off a suitably old Linux distribution for
maximal portability in the AppImage.