This is mostly to avoid problems with proxy fields not finding their template field in default skin selection

so that we can reach the original context where FormBox is used.
also clean up modified REQUEST after rendering the target form.

- it should not hide rows when no search criterion
- set form type to form_dialog

The attempt to make sorting stable in commit
28698f35
was broken because there may be pairs of items that can't be compared,
and list.sort() relies on < transitivity.

so that portal_types.Person.getTranslatedTitle() is translated

so that the error is much more visible when the validator itself fails.

support sort_key_method in Resource.getPriceParameterDict() and rewrite Movement_getPriceCalculationOperandDict using it.

Not only for performance, but also because they would break documents
on which asComposedDocument is used.

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.

Preliminary commit only to indent a big section of code.

Before we dropped amounts with quantity=0 and we stopped doing that because
it broke expand. However, there's still one case when such amount can be
ignored, i.e. when there's no base_application set on the amount generator.

When a user explicitely enters 0 on a Trade Model Line, total price must be 0
no matter what is set on the resource.

Default getPriceCalculationOperandDict script calls getPricingVariable
type-based script directly if variable_additional_price is not 0.