Fix: scheduler: a successful migrate_to no longer matters for the source if there's any newer non-monitor operation there

The unpack function previously could not handle the situation where a
stop lrm_rsc_op entry is overridden by another last operation while the
migrate_to is still preserved.

This commit also preserves the behavior for the cases like the test
migrate-partial-3 regarding the parsing of the resource status after the
transition.

This is the first step to address scenarios like (It's easier to produce
with cluster property batch-limit=1):

• rscA is live-migrating from node1 to node2.

• Before migrate_to on node1 returns, put node2 into standby.

• Transition aborts upon return of successful migrate_to on node1. New transition is going to stop the rscA on both nodes and start it on node1.

• While it is stopping on node1, run something that is going to make the transition abort again like: crm_resource --resource rscA --ban --node node2

• Transition aborts upon return of stop on node1.

Now although there's a stop on node1, it's still a partial migration and
rscA is still potentially active on node2.

So even if a migrate_to is followed by a stop, we still need to check
whether there's a corresponding migrate_from or any newer operation on
the target.