Add new categories to select constraints in each step of the upgrade
Extend method to be possible filter constraint by contraint_type
Add Script Constraint document, view and actions

Also, Added constraint property sheets to Script Constraint portal type
[ERP5 Configurator] Rename _build to _checkConsistency to follow Constraint API

The logic of all Configuration Items was not changed, but now the
changes are applied only if fixit is True and the constraints are
filtered by constraint type equal configuration.

Cosmetic: Trailing whitespaces were removed in the same commit
Add test to simulate the issue with the method TemplateTool.installBusinessTemplateListFromRepository

Using the method try to install Business Templates that are already
installed, the Business Templates is uploaded on ERP5 but not used. It
creates a lot of garbage because in the end you have many bt5s not
installed.
inherit Base for reuse methods fixConsistency / checkConsistency
Simplify erp5_upgrader to be possible upgrade any project just enabling the alarms that all Constraints will be called and fixed.

The alarms were renamed to cover each step of upgrader and give the possibility to call each step manually one-by-one. Also, all Scripts that the logic can be done by installing Business Template was removed.

Also added:
 - Constraints that can be used in the upgrader
 - Unit test to check different scenarios
 - Extend external method to be possible dump workflow chains to be compared with all configuration defined on Business Templates
Add Business Template with Constraints as a example of bt5 with all configuration required to upgrade
Clean up the code to a Folder not call checkConsistency recursively
Add ConstraintType property sheet to all constraint portal types
Improve code because is not needed call fixConsistency twice

Also, consider the error list when fixit is False only
Base.checkConsistency: s/error_list2/extra_error_list/
Add constraint to be possible call checkConsistency recursively to specific portal type

To backward compatibility, this constraint was enabled to portal types that are required call checkConsistency recursively

Portal types with recursive checkConsistency: Leave Request, Group Calendar, Group Presence Period, Presence Period, Person and Accounting Transaction

Also, added test to check the constraint RecursiveCheckConsistencyConstraint
runUnitTest script: Don't set duplicated paths on repository list
Display constraint_type field to all constraint forms
Revert "Display constraint_type field to all constraint forms"

This reverts commit e9ee549e607ce857068d5f7ddc2d7b1a458368bb.