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.

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

Also, update BusinessTemplate fucntions according to changes made after migration

No need to add Catalog Tool via the earlier manage_addProduct as it is an ERP5 object now

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.

- Rename reindexObject in CMFCatalogAware to be compatible to use in CatalogTool
  as we have renamed the reindexObject in CatalogTool

Some changes :
1. Add title for catalog tool and filter meta_types only for CatalogTool object
2. Solve the conflicts due to change in inheritence.

Also, update in BusinessTemplate installation with changes in portal_catalog

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

The ImportFixer AST processor wasn't correctly handling the alias
for imports. Now it takes them into consideration correctly. A test
to cover this case was added.

The old hack used to catch some exception is not required anymore.
The bug is gone with upstream updates.

So that a jump to the attachment file can be performed

/reviewed-on nexedi/erp5!158

This is a duplicate of !150, because by unknown reasons it's showing problem to merge.

Before, we we're redirecting `sys.stdout` and this doesn't play nice with the
distribute architecture of ERP5 and our Jupyter kernel needs to be adjusted for this.

So, we're now using an AST processor to fix print calls. It will modify the print
and make it write to a different file-like object. All the writes are collected
after code execution and sent to Jupyter.

It's still necesasry though to fix print inside other libraries. But for this
deeper investigation is necessary because we cannot replace print as a statement
inside `exec` contetx, it needs to be used as a function. Code can be compiled to
run with `print` as a function, but then external libraries calls will be
broken.

/reviewed-on nexedi/erp5!157

@Tyagov, please review.

Errors currently captured:

- environment.define call 1st argument is not a function and/or 2nd argument is not a string
- environment.define call argument is not a string
- environment.undefine trying to remove a function that is not in the environment

Proper tests were added.

/reviewed-on nexedi/erp5!144

  Performance tests were reconfigured on a new hardware, which is slower them
  the previous one. So this commit move the values to the new hardware based on
  the results after few days of result.

This is very helpful when a warehouse is splitted into multiple
stock points.

Also avoid returning no stock optimisations if no date could be
found in future.

If for some reasons loadClass was not working, it was failing totally
silently without any log. If there is any unexpected error in loadClass,
this ended up for example having some tests failing with :

RuntimeError: Malformed property definition <persistent broken
erp5.portal_type.Acquired Property instance '\x00\x00\x00\x00\x00\x00\x12\xb5'>
on /erp5/portal_property_sheets/SimpleItem

While only this was displayed in logs :

ERP5Type/dynamic/lazy_class.py", line 350, in loadClass
    class_definition = generatePortalTypeClass(site, portal_type)
...
AttributeError: __of__

Which was totally unrelated to the real problem.

So a silent initial error was the source of later unrelated errors, making
it very difficult to find the initial source of problem.

So make sure we have logs as soon as we are not able to load a class.

erp5_invoicing: Invoice Transaction Simulation Rule can also expand from Pay Sheet Rule (which is basically an invoice)

erp5_payroll_l10n_fr: adds new Types of Documents used to produce a French Social Declaration Report called DSN (Declaration Sociale Nominative)

The new modules are the Social Declaration Report Module itself,
and the Payroll Enrollment Record Module, to add some information
about every employee's working contract.

erp5_base: updates the Career view to add one new field to differentiate company and establishment, and one to attach records.