This will replace various incomplete adhoc solutions for this in the VDV
ticket parsing. It will also be helpful for decoding at least parts of SBB
and Thalys ticket codes.

This currently only does the bare minimum, proper type decoding and
recursing into nested structures would also be useful, as well as support
for built-in primitive type content.

Wont help immediately, but should come in handy when dealing with CI
update delays in the future.

So far this is just recovering our own custom property if present, which
is needed by PBI.

This allows us to show this in the app about screen too, not just in the
command line tool.

This allows us to show this in the app about screen too, not just in the
command line tool.

This in itself doesn't produce useful output yet (we need more work on
VDV ticket parsing for that), but it is already producing enough to trigger
custom extractors on.

This can still be improved by decoding sub-CA certificates offline, and
dropping their signatures.

So far this only manages to correctly decode the begin/end time, the rest
still needs a bit more quality time with the hex editor.

Unfortunately this seems to yield nonsense still, so need to figure out
which of the parameters is wrong here.

Next step is to actually implement the ISO 9796-2 decoder, that's going
to decide whether this whole thing actually works out.

In theory this should give us the needed RSA parameters for decoding the
CV certificate now.

Those are common among German local transport providers, and visually look
like UIC 918.3 codes. Unfortunately the description of what they are valid
for is entangled with their cryptographic signatures, which makes it
necessary to deal with all that here as well to get to the information we
are interested in. I only have partial documentation for this, so this
might take a while...

This fixes the build with Poppler 0.83.

Matters for a minimal static build of the CLI extractor.

Also, add better diagnostic infrastructure for the comparison functions,
to replace the current local ad hoc debug output, same as already done
for the validator.

For now this just reports top-level rejections, but this can be extended
as needed to eventually replace the need for local ad hoc debug output
when debugging validation issues. Since this is quite noisy, it makes
sense be able to disable that separately.

Also, make it accept reservable types next to reservations as top-level
objects too. This is needed for PBI.

This will replace the implementations of IataCode and CountryId, and avoid
the code duplication in the now also needed 3-letter country code table.

Needed by KItinerary Workbench.

This is a preparation step to expose this to tooling and/or extractor
scripts.

Needed for the extractor editor in KItinerary Workbench.

Still needs public access and iteration API to be useful.

We will need to export more of this, for use by KItinerary Workbench.

Needed by the CLI extractor and KItinerary Workbench.

This is duplicated in a few places at the moment, this will allow us to
unify things.

Basically stuff that is needed in the app and will also be needed in the
KMail plug-in.

Will allow the app to register for handling those.

This will allow us to store e.g. PDF files or emails with the source
information for a reservation.

Turns out there are tickets using U_TLAY ticket layouts but without
following the RCT2 standard. This now allows extractor scripts to deal
with such tickets.

This is needed for transferring multiple reservations and associated
documents (pkpass, PDFs, emails, etc) in an atomic way, without losing
their associations and meta data. We already now have problems getting
stuff from KMail into the app via KDE Connect, and things will get much
more complicated once we support attaching random documents as well.

Additionally, this will give as an easy way to export (and import) the
entire data set of the app, which is particularly important on Android,
where there is no other way to backup the data without root access.

Also, move the extractor device class to its own file. This already
produces the right images, but we still have feed this into PdfImage
to make it actually usable.

This is needed for dealing with vector barcodes.

Not much used yet, but will be needed for the upcoming vector barcode
support.