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.