Now we have multiple remotes that can be enabled or changed at runtime we need
to do several things better:
* Only load components from remotes that are enabled
* Only load a component if a higher priority remote has not already added it
Rather than just appending all recieved metadata into one big XML file, save
the original metadata .xml.gz files in /var/lib/fwupd/remotes.d and only load
them in the correct priority order if the remote is known and enabled.
Remove the old /var/cache/app-info/xmls/fwupd.xml file, also noting it wasn't
really a cache file at all but actually something quite important.
This allows us to 'tag' the components with the correct remote ID value, which
then means we can tell where the firmware information has come from when saving
a composite store. It also allows us use the correct username and password in
the future when downloading the firmware blob itself.
Keep the old D-Bus method around to preserve API for existing clients.
Add the concept of 'remotes' that can dropped into /etc and used as firmware
metadata sources. This may be desirable when firmware is only accessable with
a valid support contract or from behind a VPN.
This allows us to return multiple results from one file, for instance where the
firmware.cab file contains multiple metainfo.xml files.
This allows us to show all the entries in the firmware file, rather than
searching for the installed device that matches and falling back to just the
first listed item.
Under some circumstances a provider may want to prevent a user from
performing a flash without additional user interaction.
Providers can opt into this behavior by checking for
FWUPD_INSTALL_FLAG_FORCE in the update routine.
