Evaluate flat file export mechanism

With recent issues around our keyring, caused by bizarre gnupg behavior (#184 (closed), pacman/pacman!16 (closed), archiso#190 (closed) and ongoing issues around keyring initialization being done in time before first using pacman, etc.) I have started to think about a different way of exporting our key material and how this could be used by pacman.

IIRC the idea of immutable keyring files was first brought up by @kpcyrd sometime on IRC and I'd like to somewhat draw on that.

A large set of problems that we experience currently is due to the fact, that gnupg is being used to maintain a keyring:

• The update handling is done in a post_upgrade() call, which means that the key data is only available after the entire update process has taken place.
• Pacman-key (the wrapper around gnupg) does not use locking, which means that it is prone to break the keyring state if it is used out-of-band (e.g. by our archlinux-keyring-wkd-sync script) and that pacman itself is completely unaware of whether the keyring has been initialized at all or is still being updated, etc.

If we eliminate gnupg from this for a thought experiment, we end up in a situation, where we could also use sq to validate a signature of a package:

• A PGP keyring consisting only of the valid packager keys (and for verifiability the main signing keys) resides e.g. in /usr/share/pacman/keyrings/archlinux.pgp
• Using sq verify --signer-cert /usr/share/pacman/keyrings/archlinux.pgp --detached $package.sig $package we can verify a detached signature
• We are able to only provide the valid packager keys and remove all old ones
• We do not break our keyring as it is directly the one packaged in archlinux-keyring and requires no further processing

Unresolved situations in the proposed new/additional behavior include:

• Out-of-band updates (e.g. pacman itself fetching new keys via WKD, or archlinux-keyring-wkd-sync fetching updated versions of keys) can not be done, unless we allow for a temporary directory for secondary evaluation (e.g. /run/pacman/keyrings/$key.pgp holding a temporary download of a key encountered during update but not being in the keyring yet, and allowing the tooling to also make use of this additional temporary location).
• The web-of-trust on user systems is no longer relevant (which is likely also a good thing)

Seen from the standpoint of this project I believe this new/ additional approach would make a lot of sense, but it also adds additional responsibility to get the export right (e.g. only fully trusted keys can be exported to the keyring file when building) and it would require changes to pacman/pacman-key to allow for sq to be used in the context of workflows discussed above.