Redesign possibility to affect RPM transaction

[pirat89]

See the PR #73 for additional info (just related PR, doesn't resolve this issue). It is expected that there will be cases (e.g. PR #35) which will require additional actions during the RPM upgrade transaction (e.g. installation of specific RPMs) based on gathered facts about the syste (e.g. configuration of specific service). Current situation is confusing as the actor preparing the RPM transaction consumes FilteredRpmTransactionTasks msgs. However, people usually want to find something how to add new task and from that point the RpmTransactionTasks model is the one that looks they want to use it (even regarding additional actors, e.g. the transactionworkrounds actor.

We should rethink our current design a little here and modify it better, so it will be clear and intuitive what users should use.

NOTE: It is possible we will want to use the "filtered" data for reporting purposes - that means, by actors inside ChecksPhase - in furure.