This implements dependency resolution to sort amount generator lines
so that a base_amount is never contributed after it was applied.

Before, it was required to sort manually using int_index or float_index, which
can be difficult for a human when there are many lines spreaded over different
containers (which are merged by composition). Another problematic case is when
a set of lines is configured by a user (like discounts & fees) and must all be
applied before other lines (taxes) that are installed elsewhere by the
developer: how to reliably make sure the latter have index values that are
already greater than those entered by the user ?

Setting int_index or float_index is now only useful for lines:
- with same reference: only the maching one with lowest index is taken
  into account (commit 68ec6bda)
- applying to intermediate values of some base_amount
  (commit 10be013b)

The difficult part to solve dependencies is that the calculation for a
given base_amount may trigger the application of other base_amount, and so on
recursively. In order to support this case, amount generator lines are first
applied on a dummy amount, and getGeneratedAmountQuantity must be call
unconditionally for all dependent base_amount. So optimizing like

  return 3 <= delivery_amount.getGeneratedAmountQuantity('base_amount/1') \
      or 1 <= delivery_amount.getGeneratedAmountQuantity('base_amount/2')

is wrong except if 'base_amount/2' is only contributed by the movement or if
you sort manually with indices.

Dependency resolution has precedence over indices. But since the sort is stable,
lines will remain sorted by index if it respects dependencies.