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 !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.

The item of produced resources must not be reused on consumed resources

in some rare cases, proxy was still alive for unknown reasons,
thus we had troubles to start a new one. some testnodes were failing
randomly because of this

This change solves the error which one gets while trying to access properties
Form for an ERP5 object having one or more of its property of type 'selection'
or 'multiple selection'.
For example: If you try to access property form for any portal_type objects,
you'll get an error : "'select_variable' is not defined". This is because of the
absence of the property 'select_variable' for the property of type multiple selection,
which in case of portal_type object is 'Property Sheet List'.

This is helpful for ERP5 views/forms which displays selection or multiple selection
type object.

ERP5 Subcategory: Remove '_'(underscore) from 'multiple_selection' subcategory in elmentary_type category.

Subcategory 'multiple_selection' has been renamed to 'multiple selection' to maintain consistency.
Earlier, whenever a new StandardCategory object was created with property_type 'multiple selection',
one needed to change the elementary type explicilty to use it to generate property setters and getters.
The example for this can be seen from this commit:
nexedi/erp5@fd738753
After this change, in the view, property type field couldn't recognize the property and displays
(???multiple selection).

Also, everywhere in erp5, list_types do mention 'multiple selction' and not 'multiple_selection'.
So, its better to maintain consistency in naming the subcategory.