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

See merge request nexedi/erp5!1243

padding too much in buttom make header bigger, so when export to pdf, header is cut off to hit heigth which make logo display at top

also needs to be declared in hidden content types to prevent adding
directly in preferences

should be same for cases where type based method is a python script, but
is a bit more explicit/safe and consistent with other usages.

In 93e30e5e (Person: Store user id in new user_id property., 2016-12-09)
we adapted this test to the new behavior: title fallback to user_id or
id, but since persons always have a user_id by default, this test was
changed to check that title fallbacks to user_id, but the name of the
test still mention "fallback to id" which became a bit different from
what was tested here.

Revert testEmptyTitleFallbackOnId to check that title fallbacks on id,
using persons without user id and introduce new
testEmptyTitleFallbackOnUserId to describe the new behaviour with user
id.

See merge request !1244

See merge request nexedi/erp5!1241

See merge request nexedi/erp5!1239

1. title is not exact match
2. can't search title in objectValues

Configuration generated by Standard Configurator was not really good. For most divergences, there was no solvers configured, so users could not configure divergences. Now solvers (for packing lists) are configured so that every divergence is automatically accepted, we only expect user to take a decision when quantity or resource is different.
This change was implemented in the rules from `erp5_configurator_trade_template`, but because several simulation tests were relying on the fact that "changing anything would cause a divergence" the previous rules configuration are kept in a new `simulation_test_trade_template`.

Also, security configuration was incomplete, since the introduction of "new simulation", some Unauthorized errors occurred when non-manager users where trying to solve divergence. This is now solved and exercised in the integration tests we run on auto-configurated instance. 

The configuration was obsolete, nowadays we use different business processes for each use case, this configuration was still using only one business process for both sale and purchase, now we use two and improve the accounting configuration, to use accounts defined in supply line.

Some others small improvements were made, for example now we can configure the delivery solver to use for a split solver once and for all in the solver and user does not have to choose each time.

What not updated this time:
 - divergences on Invoice Lines: this is probably same as on Packing List before these changes
 - rules are still configured with ad-hoc scripts and not based on trade phase categories.

See merge request nexedi/erp5!1221