ZODB Components: erp5_trade: Migrate TestOrder{Mixin} and all Unit Tests inheriting from these classes.

Also, Split testInvoice to a Module Component in erp5_invoicing for Mixins used
by several other tests and Test Component in erp5_simplified_invoicing (initially
everything was migrated to erp5_invoicing but this does not work as Alarm_buildInvoice
is different in simplified and advanced invoicing).

efd71291 added on erp5_invoicing a test dependency on erp5_advanced_invoicing.
However, testRule for example uses erp5_invoicing but not erp5_advanced_invoicing
so this would not work.

Moreover, erp5_{simplified,advanced}_invoicing enhance erp5_invoicing by providing
a container for Invoice Line so to match real world use cases it is better to
have two CodingStyle tests: one checking erp5_invoicing+erp5_simplified_invoicing
and the other one erp5_invoicing+erp5_advanced_invoicing.

Also, fix CodingStyle issues on erp5_advanced_invoicing.

This reverts commit bc67c2c4.

This is seem to stall testFunctionalAdvancedECommerce with this error:

      Module script, line 5, in Workflow_ensureUserId
       - <PythonScript at /erp5_portal_7f1517681f85de9695ca475d69c4d66f/portal_workflow/login_interaction_workflow/scripts/Workflow_ensureUserId>
       - Line 5
        user = state_change['object'].getParentValue()
      Module AccessControl.ZopeGuards, line 87, in guarded_getitem
        if getSecurityManager().validate(object, object, None, v):
    Unauthorized: You are not allowed to access '2' in this context

let's revert for now, we'll re-do this with more tests.

New dependencies were added in nexedi/erp5@206a8e25

See nexedi/jio@24b938cb

Should fix most of the cases where reloading components cause breakage.
There is still a race condition between a transaction's cache being
actually flushed (which can only happen at transaction boundaries) and
another transaction doing the actual class reload, which will
immediately affect all the started transactions in the same process.

Once a portal type class became available again, instances of this classes
should no longer be broken and can be modified again

Some other types (Gadget Type) are currently lacking the interaction workflow
which resets the dynamic classes.

Persons created before the introduction of ERP5 Login and user_id will only
have a user_id after migration if they were already user before migration,
otherwise they will not have a user_id and creating assignments and ERP5 Login
for this person creates a user which can not log in the system.

To make it possible for these persons to login anyway, we ensure person has a
user id when validating a login

while setting an initial user id should be allowed for any user which can
create a person, changing an already set user id can have security
implications, so we protect it with a more strict permission

user_id are technical things that should not be displayed to users.

In the case of tokens, for now we show "something that's not user id / not the
token secret". That's not ideal but as far as I know whe don't really have use
cases of tokens to show a page where user caption would be displayed.

Person.setUserId is heavy, it serializes person module to prevent concurrency,
but in some cases we the risk of having duplicate user ids is under control, so
we don't want to pay the performance price.

See merge request !1242