Transition to AppStream's libappstream

Hi!

This WIP MR makes GNOME Software use libappstream from the AppStream project, instead of libappstream as discussed before and tracked in #1097 (closed)

Why would we want this change?

• The YAML support in libappstream is much more complete than the one in appstream-glib, which is a huge advantage for Debian and Ubuntu users who will enjoy more metadata once this change is done.
• AppStream supports new features like the mobile-compatibility features (input-controls, display dimension requirements, ...), new formatting options for description texts, artifacts and other stuff.
• Having two implementation of the AppStream specification was a point of friction in the past - focusing on one will simplify things a lot and give users a clearer source of what is specification-compliant (this is a work-in-progress task though that only just started).

What are potential problems?

Appstream-glib and libappstream have a few key differences, besides naming differences:

• The equivalent to appstream-glib's unique-id, the data-id, is only 5 elements long (missing the component-type component, as that isn't needed for uniqueness) so they don't match cleanly. GS has been asjusted for that, but we may find more issues while testing.
• The _OS_UPGRADE component-kind of appstream-glib has been mapped to AppStreams _OPERATING_SYSTEM component-kind, but they are not equivalent - a "OS_UPGRADE" component is the upgrade itself, while "OPERATING_SYSTEM" is a component describing the current OS with new releases being part of the <releases/> tag. This stuff likely needs some refactoring in future, at more places than just GNOME Software (but since AFAIK only Fedora uses this at the moment, it's hard to test for me).
• The AS_URL_KIND_MISSING URL kind does not exist in the AppStream specification to show a URL when a component has no installation candidate. Personally, I would integrate the functionality of this feature into a new "repository" component which could include explanations of how to enable it to add new features, but that's probably something for @hughsie to comment on. I would also not be completely against adding this to the specification, but I haven't given this enough of a thought yet.
• AppStream doesn't support "kudos", so most of the kudos will no longer show up (this should not be much of an issue though, as most of them were not visible anymore anyway)

There's also some transient issues:

• AppStream upstream has been extended with some features previously present only in appstream-glib. Also, a lot of its previously private API is now exposed for GNOME Software to use (as GS needs a lot more fine knobs than e.g. Elementary's AppCenter). This means you need AppStreamäs git master (from here) in order to build this MR. AppStream itself will likely build anywhere GLib >= 2.58 is also present, but this of course is a requirement increase.
• The GitLab CI jobs don't get the new AppStream yet, so CI jobs fail at the moment

Current Status

• Add GsAppState standalone to GNOME Software master
• Port to libappstream
• Drop shell extension support remnants
• Automatic tests work
• Displays & installs applications
• Screenshots work
• Icons work*
• Test on Fedora
• OS updates show up and work
• Test Flatpak support
• Implement solution for _URL_MISSING
• Implement solution for _OS_UPDATE pseudo-apps
• Additional (performance) testing
• AppStream 0.14.0 release

How to test

Just apply the patches from this MR and build GS as usual (Meson should take care of fetching a more up-to-date libappstream if necessary). Then run gnome-software and see if everything still works.