We don't actually need either of the things it provides (looking up in source
and built, and converting to an absolute path) so just replace it with
g_build_filename() instead.
This also has the advantage that it does the right thing on Windows.
This was a new file format to help out an OEM, but they didn't actually use it.
If we do need it in the future, it would some back as a src/ helper, not in
plugins/dfu.
We don't support any hardware that actually uses this proposed standard, and
nowadays there is much better public-key encryption people can easily use.
In many plugins we've wanted to use ->prepare_firmware() to parse the firmware
ahead of ->detach() and ->write_firmware() but this has the limitation that it
can only return a single blob of data.
For many devices, multiple binary blobs are required from one parsed image,
for instance providing signatures, config and data blobs that have to be pushed
to the device in different way.
This also means we parse the firmware *before* we ask the user to detach.
Break the internal FuDevice API to support these firmware types as they become
more popular.
This also allows us to move the Intel HEX and SREC parsing out of the dfu plugin
as they are used by a few plugins now, and resolving symbols between plugins
isn't exactly awesome.
Five plugins (soon to be 7) are linking to the DFU plugin just for this simple
segment-aware chunking functionality. Move this into common code to make
building simpler.
This is slightly more verbose than desired as we also have to include the quirk
information when running the dfu-tool, which does not have an already set-up
FuQuirks object as it has no plugin.
