When the child has completed we rely on the next fu_progress_step_done()
call to set the status value back to the parent-defined value. In the
case where there is a delay until the next step is done (e.g. waiting
for hardware to re-enumerate) the child status persisted incorrectly.
It's actually quite hard to build a front-end for fwupd at the moment
as you're never sure when the progress bar is going to zip back to 0%
and start all over again. Some plugins go 0..100% for write, others
go 0..100% for erase, then again for write, then *again* for verify.
By creating a helper object we can easily split up the progress of the
specific task, e.g. write_firmware().
We can encode at the plugin level "the erase takes 50% of the time, the
write takes 40% and the read takes 10%". This means we can have a
progressbar which goes up just once at a consistent speed.
