This adds a few checks and cleanups for the release metadata, most
importantly validating the release dates for correctness.
See issue #245 for more information.

This resolves #245

This was already made clear in the spec part of the documentation, but
the quickstart page was not up to date.

The answer is: Pretty much use .metainfo.xml all the time, unless you
have a desktop-app in which case you may choose .appdata.xml (which will
likely be supported forever for legacy compatibility).

We don't use deprecated API anymore and are slightly faster.
In theory we can get rid of a few more allocations here, but let's see
if that is actually needed for better performance.

Currently translated at 100.0% (197 of 197 strings)

Currently translated at 100.0% (197 of 197 strings)

This is nice for automated tools that need to read this data for further
processing.

Previously, AppStream would read and releases from metainfo files, then
ensure that they were sorted and make a sorted list of releases
available to the user.
Now, we only sort before data is serialized, not when it is loaded.
Additionally, the validator will emit a warning (failing validation)
when releases in a metainfo files are not sorted correctly.

A latest-to-oldest release info is now be strongly advised ("should")
for metainfo files, while being mandatory for collection metadata
("must").
We might enforce this ordering for all metainfo files soon, if there are
no issues found with this change.

Currently translated at 100.0% (197 of 197 strings)

By default, `appstreamcli validate*` commands will now display a terse
list of found issues. You can pass `--explain` to the command in order
to get a detailed explanation on the individual issues.

Currently translated at 100.0% (197 of 197 strings)

Currently translated at 100.0% (197 of 197 strings)

Currently translated at 100.0% (197 of 197 strings)

Currently translated at 100.0% (197 of 197 strings)

Currently translated at 79.7% (157 of 197 strings)

Currently translated at 100.0% (197 of 197 strings)

Currently translated at 100.0% (197 of 197 strings)

This is rudimentary for now and will look much better soon.
But it allows to test the new validator more easily in the master
branch.

With this new validation system each issue gets a long explanation as
well as a unique short tag which can be used for display it better in
UIs, ignore it or just quickly infer what the problem is.
This is a semi-breaking change as it will change the validator output,
so this will receive further updates in the next few days to make it
work better and display the output better.

Currently translated at 100.0% (197 of 197 strings)

Currently translated at 79.2% (156 of 197 strings)

Currently translated at 100.0% (197 of 197 strings)

This is just to make naming consistent everywhere, in the code as well
as in printed messages.
For validation, severity == importance

This particular case of a component being an addon to itself is
nonsense, but people may make that mistake and we shouldn't crash in
that case.
With this patch the cache will be resilient against such cases and
simply ignore components depending on themselves.
We could still get nasty dependency loops though, with A depending on B
depending on A. This is a bit more complicated to resolve and will be
fixed in a future commit.
Resolves: #243

This should not fail, ever, unless we run out of memory. But since I was
looking at that code, having a sanity check here is better in case this
does become more relevant in future (and simply because not checking it
was not good prectice).

Currently translated at 12.7% (25 of 197 strings)

Ensure we never accidentally free unallocated memory.