Also no Variables are needed for Interaction Workflow

Migration of configurators needs to be redone in order to keep ids of objects.
For now, the migration can not be reviewed seriously since all sub objects have
different ids. May be it might make sense to correctly name ids in generic erp5 first.

Migration is mostly :
* changing portal type "Transition" to "Configuration Transition"
* changing portal type "State" to "Configuration State"
* changing portal type "Variable" to "Workflow Variable"
* changing portal type "Workflow" to "Configuration Workflow"

it was a coincidence that the first event was set by edit_workflow during
initialization: it was due to workflow list not sorted in chains_by_type

Variable type is now called Workflow Variable
Add automatic_update property on variables
Rename initial_value to variable_value

- general refactoring (renaming variables and methods for better consistency,
improving views, fixing tests, ...)
- performance improvements
- rework of guards
- rewriting permission/roles matrix on state
- use patched version of updateRolesMappingFor and rework it for cases of many
workflows setting different roles for the same permission
- fixes of troubles when having prefixed state/transition/script in new
workflows
- ...

ZBigArrays were omitted from being saved in notebooks in 5fb16acd
(erp5_data_notebook: Don't save ZBigArray in data notebook. It may be
too big that zope process may crash.).

However since ZBigArrays are regular ZODB objects with persistent
references to other ZODB objects there is no reason for us not to be able to
serialize them.

Add corresponding FIXME with link to more context.

/reviewed-by TrustMe

Currently the full-upgrade alarm calls the 3 upgrade-related-alarm's activeSense methods in activities. As activeSense method runs Alarm's methods in activities too, the final activities do not get the good "tag" and "after_tag" values, which creates a lack of depency between them. In consequence, if we are not running the real upgrade (= just activeSense), no need to run post-upgrade's activeSense : indeed, post-upgrade constraints will be run on what are *currently* installed, and not on the result of the previous steps of the upgrader, which lead to a wrong and misleading consistency check.

This Merge Request intends to fix it by : 
   * Adding a "activate_kw" parameter to activeSense method, which allow to configure its internal call to "activate"
   * Improving upgrader to remove the useless calls to activeSense, and properly parameterize activeSense's activity generation 

/reviewed-on nexedi/erp5!276

For new developments, we should use portal_components. So move theses tests to
portal_components before Workflow changes.

There is no selenium tests yet, but at least we can see the same graph rendered with different
gadgets. Later, we will have to find smart ways for testing graphs

[erp5_officejs_appstore_base] configuration_latest_version is set when acception the Software Publication

Fix web section templates.
Fix appcache for the redirect app.

FullUpgrade Alarm relies on getLastActiveProcess to return results, which makes
use of the catalog to return a result. If the Active Processes spawned by the
3 Alarms composing the upgrader (pre, upgrade, post) are not indexed before
the FullUpgrade Alarm collects the results, then the wrong active result is
returned, which then give the wrong feedback to the user.

It seems that the "defaultActivateParameterDict" method cannot overwrite
the "tag" parameter of indexation activities (even if it was working for
after_tag). This is why this commit is needed.

to fit original script behavior, from erp5_web skin folder.
Also fixes "KeyError: TraversalRequestNameStack" from
`WebPage.getDocumentValue(reference)` on the "View" skin selection.

This activate_kw is a dict passed to internal 'activate' called
in order to more controls on activities created by activeSense

As results may be inconsistent as long as pre-upgrade and upgrade steps have been run for real