Signed-off-by: Morten Linderud <morten@linderud.pw>

When importing a non reduced keyring the certifications were not
deterministic for keys that have multiple certifications per issuer.
This was for example the case for self certifications to extend the
expiry time. Before this commit a random certification could remain the
final one which would lead to a non up to date keyring and a potentially
expired key.

Fix the assembling of a certificate by joining the packets in the
correct order and splitting combined files into individual single
packets per file.

This helps to identify if a certification issuer comes from a main key
or not.

We duplicated resolving usernames and fingerprints to actual keyring
paths in multiple places. De-duplicate the code by using dedicated
functions to do this job.

Only do so when listing all keys, when a filter is provided, like
usernames or fingerprints, keep the order to allow a 1:1 mapping.

We do not need to duplicates packages in certifications and revocations.
Store the packets separated from their parent as those are already
persisted.

This helps make the CLI more useful by listing, exporting or inspecting
a specific fingerprint.

All modern tooling already reads type hinting from the signatures
instead of the docstring and supports annotating the parameter
accordingly. Remove the duplicated data to avoid out of sync
documentation.

The API makes more sense to return (trusted,revoked) as the caller can
simply derive all certificates by joining the two sets.

To simplify the functions, some code has been replaced to use helper
methods to flatten the nested loops.

By collecting the matching usernames to all fingerprints we are able to
enrich the output of `inspect` to show the usernames next to the
certifications.

This way we can reuse the functionality which will allow to simplify a
lot of places that have multiple layers of inflexible nested loops.

This aids initial imports of keyrings that contain multiple certificates
by allowing keyring_split to enforce preserving the filenames. This is
achieved by moving each split keyring into unique sub directories where
the original input filename remains unique.

When we import new packet data, always allow overwrites of the final
packet files. This may happen when importing from multiple files that
provide the same packets, which is fine as they should still yield to
the same results.

This command prints a new and pretty representation of the certificate
data to visualize the keyring and its signatures.

This allows an easy to use cli which invokes the export function to get
the keyring and uses the ownertrust and revoke functions to write all
artifacts into a target directory.

This gives more control over the export command that may be useful to
export a single packager to import it into gpg. This will also give more
flexibility to chain this function to the future verify stage.

By default the command exports the whole keyring directory.

Lets pass in a list of path's and reduce them to one set of path
iterables. This allows us to specify multiple source files/directories

Both commands are basically doing the same with the same params except
the target directory differs. Lets condense this behavior by using a
single subcommand with a boolean options.

Instead of always returning an artificial name try to preserve the
keyring filename if the split only yields a single certificate.

This helps to structure the layout of the repository better by having
one root folder that contains the actual decomposed keyring structure.

So far we have used singular for all directories, lets keep that for the
packager directory as well.

Allow short key id fingerprints to be used with the username derive
function by adding a glob in front of the fingerprint component.

Move the name cascade to derive the username into the
`convert_certificate` function which allows to use the
certificate_fingerprint directly instead of trying to find it by
splitting the certificate one more time before converting.