erp5_catalog: Do not use selection elementary type for properties in Catalog and CatalogTool property sheets

And define the mentioned property sheet on Template Tool portal type. This is
necessary as while running the post_upgrade constaint 'migrate_catalog_constaint',
the script will run only if the portal_type it is defined on is indexed in the
catalog. But if we define it on 'Catalog Tool' portal type, it won't be called
as it can't be indexed before migration, so it is better to define on 'Template Tool'.

If needed, we can change the name of the property sheet to honor naming
conventions. Also, it makes more sense to have migration script in portal
skin 'erp5_upgrader' as it is also a part of upgrading erp5.

** Add test for migration of catalog via portal_alarm

** Also, update the other tests where it was taken for granted that
there are no constraint for 'post_upgrade', as now we have added
an extra post_upgrade constraint in erp5_upgrader bt5.

Both SQL Catalog and the new ERP5 Catalog have all properties as their
attributes also, so its better to user `getattr` as it'll maintain
consistency betwen both.

This was required as in ERP5 Catalog, these properties are multivalued
propeties, so they have multiple accessors, so if we use 'getProperty',
we won't get the objects we desired. So, instead of relying on that, why
not just use the attributes.

Also, add test for migration in testERP5Catalog(as the first test to be run)
and migrate Catalog in afterSetup in testERP5CatalogSecurityUidOptimization.

Also, migrate the catalog before running tests

What we expect during migration:
1. Copy objects as well as properties from SQLCatalog to ERP5Catalog
2. Migration of SQL Methods and Python Scripts as ERP5 objects
3. Update migration with filter_dict for methods

The migration function would now create portal_catalog based on
'Catalog Tool' portal_type and after that it'll migrate the objects
(catalog, SQL Method, Python Scripts) in it.

Also, update BusinessTemplate fucntions according to changes made after migration

Contains views, property sheets,  portal types concerning shifting of
portal_catalog to an erp5 object.

Portal Types:
1. Catalog : ERP5 Catalog object (an ERP5 Folder), which earlier used to be OFS Folder.
2. Catalog Tool: Portal Catalog where we can add and use multiple ERP5 catalogs.
3. SQL Method: SQL methods with their views inside erp5.

Property Sheet:
1. Catalog
2. CatalogTool
3. SQLMethod
	Containing properties for the various portal_types/classes respectively.
4. CatalogFilter

Also, filter_dict for erp5_catalog would now not be a Persistent Mapping
object. The info inside filter_dict is being saved inside the SQL Method
objects as their properties.

Views:
1. Catalog (View)
2. CatalogTool(View, Properties, Filtered Items), Object Actions
3. SQLMethod (View, Filter)
4. Python Script (Filter)

Extras:
	- Dialog view for catalog before clear_catalog

Its better to change the tests where they need to call getpath function of
portal_catalog to use portal_catalog.getpath instead of portal_catalog.getPath,
as we have overridden the 'getPath' function for CatalogTool class due to change
in inherited class.

- This step is needed due to the use of BaseTool as Base class for CatalogTool
  due to which there were conflict between getUrl and reindexObject from the Base and the one
  from the BaseTool.

- Update CMFCatalogAware patch to handle case for catalog tool for 2 different meta_types

Also, update in BusinessTemplate installation with changes in portal_catalog

Better to create new module for new Catalog Tool, as we don't
want a running instance to fail just because it is updated by
the new catalog code. This will maintain consistency in case
user doen't want to migrate to new catalog/catalog_tool

Most of the code for ERP5CatalogTool is copied from CatalogTool.

We try to move from using SQLCatalog to ERP5Catalog as the default Catalog inside
ERP5. The major difference is use of Folder class as the base for Catalog from
Products.ERP5Type.Core

Significant changes:
	-Add dtml form for creating ERP5Catalog object
	-Inherit from Catalog class from Products.ZSQLCatalog.SQLCatalog instead of copy-pasting the whole code again.
	-Add allowed_types for ERP5Catalog tool
	-Monkey patch some property setters and getters to maintain consistency
	-Update id and title for ERP5Catlog while class initialization
	-Set declarative securities and solve some inheritance conflicts
	-Add isRADContent for ERP5Catalog Class
 	-Solve inheritence conflict for _setPropValue function in ERP5Catalog class
	-Add SQL Method portal_type in allowed_types for ERP5Catalog class
	-Override getCatalogMethodIds cause it uses global variable in SQLCatalog.Catalog
	-Redefine security declarations
	-Add functions for object_actions of Catalog portal_type in ERP5Catalog object
	-Add filter_dict and _properties attributes for compatibilty

because objects will be lost.

At same time, simplify code a bit :

- Just use _migration_in_progress attribute directly instead of a variable.
- Set a default value on class, so that we do not have to getattr.
- Do not use  aq_base, this is useless for attributes starting with _

With previous algorithm, work was given to additional test nodes only when:
- we were previously below the needed capacity
- when another test node was dying

Now, as soon as a new test node is added, we move work of overloaded test nodes to
idle test nodes. We try to move only test suite using many test nodes to avoid having to
wait for building time.

This allows to have better distribution of the work with the idea to have more quickly test results.
This will avoid cases where we have several testnodes assigned to no work at all.

Finally, fixed distribution algorithm to avoid some unfair cases where a test suite might
have more test node than another while they both ask for the same number of test nodes.

Documentation says this step is done in one transaction, so implement
this as documented.

Detecting developer mistake and automagically running this step in smaller
transactions if more than 100 documents seems unnecessary. At least, it
contredicts documentation.

now that we use alarm sense method, another `notify` call is activated