lib: move prerm to be run before postinst in transaction
This moves execution of prerm script from pkg_scripts step to pkg_move step. This effectivelly means that prerm and preinst scripts are run in plan order at the same time. This solves problems where prerm disables service or in general does operation which revers one done previous preinst. There are two consideration required. This code defines content of journal. The difference is that instead of editing all_configs table in pkg_scripts we generate it in its fullest in pkg_move. That is all right and fully compatible. The more problematic case is when we update from previous version of updater and there is journal stuck with completed pkg_move step but not yet completed pkg_scripts step. The result is that in such case prerm scripts are not run and packages are not in reality removed (removed from state). The real removal happens with next updater execution. So this is self healing problem that happens only with small probability. This also does one degradation in behavior. Previously we were ignoring removal operation for packages that were intended to be installed. In that case we just skipped remove section. The problem is that pkg_move does not have to_install argument and that makes it impossible to check if operation tries to remove package that is installed by some other one. The effect of such operation in this new implementation is that we would run in such case prerm script and removed given package info from status while preserved its files in system. That is worst case scenario. Other case where install request comes after remove request returns given info to state and runs preinst. That effectively just causes us to run both prerm and preinst where it should have been reinstall. That effectively should not cause anything bad. The real reason why we do not care too much is that only case when something like that happens is when pkgtransaction is used. pkgupdate never generates two operations for same package. Because pkgtransaction is dangerous tool in general I don't see it as huge problem. Other option is to pass to_install table to pkg_move as well but we would have to take care of situation where this field is not part of journal.