During the review of simulation refactoring with Kaz, we found that it made more sense to implement movement aggregation at the applied rule level and implement and N to M matching process rather than a 1 to N. This requires AmountGenerator and MovementGenerator to provide a separate API with no aggregation. Moreover, aggregation process should if possible be implemented consistently accross ERP5. DivergenceTesters seem to be the appropriate core component for that. MovementGroup themselves could be based on embedded DivergenceTesters and getAggregated* method could use themselved MovementGroup, either temporary instances dynamically generated, or existing instances found in appropriate context. This gives an idea of future directions. However, initial implementation will focus first on stable expand.

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@31476 20353a03-c40f-0410-a6d1-a30d3c3de9de