These are needed to view and solve divergences

Because solvers are installed by erp5_configurator_standard_solver, they will
be installed without roles, so we have to recalculate roles after configuration
is finished.

When changing the resource of the variation, this has a big impact, so we
enable a divergence, mostly to be consistent with the fact that we ask
resolution for quantity divergences: if we ask "we planned for 3 apples,
instead we have 2 apples what should we do ?", it's a bit strange not to ask
anything for "we planned for 3 apples, instead we have 3 carrots"

The difference between Quantity Split Solver and Simple Quantity Split Solver
is that Quantity Split Solver asks user to select how to dispatch the
divergence on multiple deliveries, but in erp5_configurator_standard's
configuration builders are configured to buildout one packing list for each
order, so there will not be cases where this actually makes a difference.

So use the Simple version, which is easier to use for simple cases (which are
the target for erp5_configurator_standard)

In order to make solving divergences easier, we sometimes don't need to
show the delivery solver (priority) field when the solver only allow
one.

Similar to Quantity Split Solver, but using FIFO delivery solver, so
that user does not have to choose a delivery solver.

Now that erp5_configurator_trade_template rules are configured to automatically
accept divergences, they are no longer usable in tests where we want to check
that changing something cause a divergence, so introduce a new
simulation_test_trade_template business template with the previous rules from
erp5_configurator_trade_template and also the builders and make old simulation
tests use this business template instead.

Use "Automatic Accept Solver" for most divergences

a solver that can automatically accept all divergences, except on
quantity{,_unit}

Split & Defer should not be the only choice

Changing the trade condition can impact the business process and generate a
completly different simulation, so ask user instead of just silently accepting.

Using different business process is more flexible, it allows to configure
different to build at different time, to generate different accounting etc.

This introduce two different business processes and also modernize the configuration to:
 - generate accounting only for the supplier in sales
 - generate accounting only for the client in purchases
 - generate accounting using income/expense accounts defined on supplies
 - generate accounting without analytics (project, function) only for
   income/expense accounts

and to fix an "infinite loop" with tax business link, it had the same
predecessor and successor

Add support for membership criterion, to be able to define advanced trade model
paths with predicates.

This code was iterating in a dict and removing keys at the same time.

The second block was the same logic as the first, but using another variable
all along, except for the part where None keys are removed from dict. Change
this part to use the other variable used everywhere else in the second block.

Using an em html tag is enough to have to display the explanation
message differently, not need to wrap it in paranthesis, which does not
look so good in some languages.

formulator passes arguments, no need to look in request by hand. Also
this makes scripts easier to test if passed arguments are used.

This is required to be able to use solve divergence action

for now used in solver configuration only

This can help debugging test failures on test nodes

ERP5: Remove Capacity/GLPK: never used and broken since glpk Python module is not in ERP5 Software Release neither.

* Properly override WebSite Document in erp5_web_shadir by creating a new
  version_priority.
* Keep Web{Section,Site}TraversalHook in Product/ERP5/Document as these are
  not ERP5 objects. Also, add `kept_for_backward_compatibility_only` to
  importLocalDocument() to handle pattern where the Document class has been
  migrated but some code remains.
* Move WebSection_get*PrecacheManifestList Python Script from bt5 not depending
  on erp5_web to erp5_web_renderjs as this is required by CodingStyleTest
  (WebSection being now in erp5_web).

When a first migration was reverted for any reason (e.g. ConflictError),
the assertion failed because __setstate__ was not called yet to fix the
class back to the old one.

See merge request !1212

Fixes Active Process' "hasActivity" method when that document's uid is >2**32.

erp5_officejs_support_request_ui: Add begin date to the query when user click on "Last Month Activity"

The filter when the user click on the "Last Month Activity" chart filter Support Request only by status (Submitted / Open / Suspended / Closed). So on the table "Recent updates", all the support request with the chosen status appear. There is no filter by "Begin Date" for the last 30 days, which is no coherent with the "Last Month Activity". => It should appear only the support request with the chosen status with a begin date < D - 30 days

See merge request nexedi/erp5!1214

See merge request nexedi/erp5!1216