Semantically it is the desire of the security attribute, not the bios
attribute, i.e. you could imagine that a specific attribute would have
to be *foo or bar or baz* for HSI-1 and *only foo* for HSI-2
Also make it easier to add possible BIOS attribute target values in
plugin code.
This means we don't need to worry about changing multiple
implementations if the HSI levels change for a specific ID.
It also means we can fake HSI results in the future without having
to also store the 'correct' level in the input file.
We tried to solve this by matching the org.fwupd.hsi AppStream ID, but
in some cases the resolution depends on what actually failed.
Add "the action the user is supposed to do" as flags so that the
front-end can translate this in the appropriate way, for instance,
using a different string for log events and HSI dialogs.
