Payment in planned or confirmed state are interesting for user.

It is ERP5 issue if correct transaction cannot be confirmed or started and
shall be fixed.

Note: It was done in activities in order to escape from transaction and have
committed system events. But as users might need to redo payments, system shall
behave simpler.

Allow to reuse existing ID and allow PayZen to inform user, that transaction
is already registered.

Allow to work on already confirmed Payment Transaction - just do not try to
confirm it again.

Set start date a bit later.

As this is called in a loop, only try to find delivery lines for occupied
partitions.

Otherwise two queries lasting 0.3s each will be called in order to result with
None.

Delivery can be stopped by user without enough privileges.

And ExpandableItem does not have to be immediately expanded, there is alarm which
is responsible for simulation tree updates.

The KVM ordering interface has extremely simplified - customer is just one
click away from instance, so modify test to follow it.

Simplify test:

 * drop all server side scripts and rewrite AJAX calls to use already
   implemented SoftwareInstance_getStatus
 * where required implement client (browser) side analysis of data instead of
   relying on server side implementation (eg. fetching path of Software
   Instance)
 * avoid big pauses; pause just once (as client side logic to know when
   Software Instance is indexed would be cumbersome and complicated and anyway
   10s to index object is really long and shall be treat as failure)
 * flatten macros into main test for readability and beacuse they become
   oneliners

This variable is used by ./configure to guess libdir name (lib, lib64, ...). Of course we just want 'lib' to be chosen.

Show software release state and usage.
Reuse scripts from vifib_web.

Note: This is just a script directly called from URL, thus no way to find its
previous context.