keep it as compatibility code but also search for new workflow/portal_type association
directly in portal_type (type_workflow_list)
This fixes some failures in testFunctionalCore

if using id, it would check for simulation state to be for example in state_draft (id)
instead of draft (reference)
This was breaking testFunctionalCore page_templates_zuite/testSearchDialog

testERP5Catalog was failing because there was more than 1000 activities in portal_activities
and the one that should have been invoked was at the end of the list
set the limit to None, and only check the interesting activities
Also, add SQLCatalog_deferFullTextIndexActivity to activities to
play.

this test is no more relevant because chain_dict is not used anymore
and portal type/workflow association is done in portal types directly

don't try to remove non-existing worklists!
+ use getPortalType instead of __class__.__name__
+ only test guard on ERP5Worklow worklists

that are not used anymore (workflow are associated
to portal_types in portal_types directly)

non-existing getWorklistValueDict one
+ add getGuardRoleList method on DCWorkflow worklists

setVariableValue sets value to None if parameter is empty string
this breaks testWorkflowAndDCWorkflow and change the expected behaviour
take care that if someone saves a variable without editing this field, variable_value
may be None again

This fixes testERP5BankingCashMovement, because
getPortalCurrentInventoryStateList and others now returns
expected values.

in the Workflow, the status dict (used to set history) can handle None
values, and the behaviour should not differ from DCWorkflow.

This should fix SyncML test failures.

from erp5_workflow to erp5_core

when removing a workflow from a portal type, it was only using old
chain_by_type and not removing them from inside the portal type
through the type_workflow value

add erp5_workflow portal types and view to erp5_core

+ raise explicitly when history has empty transition
(this happens when there automatic_update is not true)

do not force the user to check the box...

during workflow conversion
On DCWorkflow states, when the workflow does not manage permissions,
they may appear in some states's permission_roles dict.
This create wrong permissions, and we should not set them if they are
not managed by the workflow.

remove duplicated code

not by category because the script used here are from portal_skins
moreover, they are not put into the workflow object (and thus accessible in the ZODB)
because the same script is often used in transitions from different configurator workflows

this will allow the use of proxy_roles
fixes, among others, broken tests on packing list

the private setters are called by methods like 'edit', ...

ERP5Workflow: replace use of old Variable type by Workflow Variable in erp5_configurator_ebusiness_lotse