Module result to not depend on a combination of exit_x and log_x_risk

[bocekm]

Currently it's confusing and hard to maintain for module developers, how to set exit_x and log_x_risk functions in a module and what would be the outcome, because each combination of them yields different results.

Change API for modules as follows:

• log_x_risk will be replaced with set_result (the name can be decided later).
• By calling set_result the module developer will specify, what result of the module they want in the report (pass, fixed, fail, needs_inspection, needs_action, informational, not_applicable).
• The set_result could be called multiple times within a module.
• The module will have to eventually call the exit_module function, that will collect the information from the called set_result and will pick the "most important" result.
• Under the hood, the exit_module will set a risk* if needed, according to https://github.com/upgrades-migrations/preupgrade-assistant/wiki/How-modules-affect-the-Preupgrade-Assistant-return-code, and stop execution of the module with one of the exit codes expected by OpenSCAP.

*The question is, what risk should the exit_module set if the module developer wants to have needs_inspection result - slight or medium risk?

This is a record of ideas of @AloisMahdal and @pirat89. Is it +- as you wanted?

[AloisMahdal]

Well, what I had in mind was rather that module would only have to call log_x_risk and the actual result would be inferred from that. IOW, the API should not rely on a state held in the module process. This is also why I don't think exit_module as presented here is good enough; this still depends on module not crashing and burning in a fireball.

If you want to see record of "my idea", I have already documented in https://bugzilla.redhat.com/show_bug.cgi?id=1400672; the wrapper actually implements exactly the kind of logic I think should be the "end-game".

(That said, the proposal is a bit better than status quo, OTOH bar is low on that one ;-))