Consider all planned or confirmed transactions and take actions based on
transaction status.

Avoid using started state, as it is impossible for customer to move Payment
Transaction into this state.

Just use planned and confirmed states and synchronously try to move to confirmed
when user tries to access the transaction.

Support a case when customer will leave Vifib.net site but will not finish the payment.
In such case just propose him to pay again the transaction, and if required, setup
newer PayZen integration id (eg. in case of big, like a day, delay).

In case if transaction was proposed to be paid and user sucessfully paid it before
update immediately transaction status.

If there is any payment in planned or confirmed state, expose it as to be paid
one.

While user will click, than system will try to do correct operation with payzen.

As stopped and delivered states are used in accounting reports, reuse started
state on Payment Transaction as confirmation, that PayZen was able to register
it.

Confirmed state means that user went to PayZen website, but it is not known if
anything happened.

Planned state means that transaction was not even tried to be registered in payzen.

Stopped means, that PayZen confirmed payment.

Default script from erp5_crm already provides needed functionnality to support
anonymous user.

vifib_crm can be dropped as it becomes empty.

(cherry picked from commit fc0e4e18)

Conflicts:

	master/bt5/vifib_base/bt/revision

Conflicts:
	master/bt5/vifib_base/bt/revision

Try to show interesting information about deliveries which are not solved.

Delivery with solved state.

In order to minimise amount of non merged documents build each combination of path
and (closest) explanation in one shot and lock this building.

Note: As it is impossible to create AND-ed transaction level lock SimulationMovement_buildVifib
method is "unsafe" to be called in separate transactions.

Deliveried, expanded and solved subscription packing list.

This is: planned and solved payment.

User has posted invoice and planned and solved payment.

It is now available and gives better results than uid sort.

As in testVifibDefaultUseCase there was more and more Tic one after another
start to replace them with Call...Alarm with CleanTic. This will show expected
states of system in case of playing scenario.

Add magical method to generate the alarms and reuse it everywhere.

Note: stepTic still calls all possible alarms.

They are shortly in confirmed state, and in this case expand is required even
if state of invoice line matches catalogged state of simulation movement.