liboval's data generator should support old oval data migration

[javihernandez]

After the initial implementation of the OVAL data generator, I didn't take into account that we were going to migrate the already released erratas' oval data, which brought a couple of problems:

1. When creating states, we aren't checking if the state is in oval cache
2. AlmaLinux production OVAL contains non-critical (but awful) reference inconsistencies (looks like we have a debranding issue in our current get_xml_oval processing), i.e.:

   <criterion test_ref="oval:org.almalinux.alsa:tst:20243466001" comment="python39 is earlier than 0:3.9.19-1.module_el8.10.0+3849+a48d89aa"/>

   This criteria refers to test oval:org.almalinux.alsa:tst:20243466001:

   <red-def:rpminfo_test check="at least one" comment="python39 is earlier than 0:3.9.19-1.module+el8.10.0+21815+bb024982" id="oval:org.almalinux.alsa:tst:20243466001" version="636">
     <red-def:object object_ref="oval:org.almalinux.alsa:obj:20214160001"/>
     <red-def:state state_ref="oval:org.almalinux.alsa:ste:20243466001"/>
   </red-def:rpminfo_test>

   The problem here is that the evr in the comments don't match, 0:3.9.19-1.module_el8.10.0+3849+a48d89aa (alma) vs 0:3.9.19-1.module+el8.10.0+21815+bb024982 (rhel)

And if we go further and check the state oval:org.almalinux.alsa:ste:20243466001:

    <red-def:rpminfo_state id="oval:org.almalinux.alsa:ste:20243466001" version="636">
      <red-def:arch operation="pattern match" datatype="string">aarch64|ppc64le|s390x|x86_64</red-def:arch>
      <red-def:evr datatype="evr_string" operation="less than">0:3.9.19-1.module_el8.10.0+3849+a48d89aa</red-def:evr>
    </red-def:rpminfo_state>

For that to not happen again, when processing a new test, we need to, in addition to check that both object_ref and state_ref match, check that the comment also matches.