When looking up a document by reference, using getDocumentValueList from
the context of a web site / web section might not find the documents,
depending on the predicates defined on the web site / web section.

This gadget looks up a document by reference, by using
getDocumentValueList on the context of the web section.
getDocumentValueList also applies the criterions from the context, but
because web page references are already unique, adding more criterions
can just cause the document to be not found and the gadget to display
the "No document" error.

This sort was based on the id of the role definition but this did not
work when the type definition had more than 10 documents, because:

    >>> sorted(['1', '2', '10'])
    ['1', '10', '2']

This switches to an approach of converting the id to integer, with a
fallback in case the id generator is customized.

cause by nexedi/erp5!1726

use calendar module and public DateTime API instead.

This ensures that we don't break more.

We have code depending on these attributes, they were used in pattern
like this:

```py
try:
  DateTime(user_input)
except DateTime.DateError:
  error("invalid date")
```

so it's safer to keep the attributes for now, since we are already
patching a lot

We have too much code depending on this behavior, so we keep this patch
for now.

By using iso format we create dates in UTC timezone

This is a context manager which temporary allow to change the time zone.

It is not thread safe and intended to be used in tests only, to replace
setTimeZoneToUTC and setTimezone methods by something unified which
makes the transition to DateTime 4 easier, because changing timezone
was done by patching private attributes and the DateTime 4 use different
attributes.

Use calendar module instead. These API depends on current locale, but
we don't set the locale in ERP5, so these remain in English

This is just hiding problem and does not seem needed.

The changes from ae15e7e1 (accounting: show the context when
showing invalid bank accounts, 2022-12-21) were a regression because
with the previous behaviour, by just looking at the transactions,
users could see with the ??? that something was wrong with the bank
account. After these changes they had to open the select element.

This restore somehow the previous behaviour by displaying the label
with ??? marker, but since we have the label, we display the
label (bank account reference) instead of the value (the relative URL)

This was working only with Organisations

The only check with accounting transactions regarding bank account
was that the bank account is not invalidated. This makes the
constraint more strict by checking that the bank account belongs to
the corresponding entity and also that the bank account is validated.

A few tests needed to be updated to validate the bank accounts. Also
a legacy sequence test has been removed because it is now covered by
normal tests.

The parameter is still named `organisation` for "API stability", but
this parameter can be a person.

This was already used by the fields on accounting transaction for
source/destination_payment and more or less working already, except
for the case where the person had a subordination to an organisation
member of the group, in that case instead of showing the bank accounts
from the person this was showing the bank accounts from the
organisation

On a transaction without section / mirror section, on the profile tab
all accouts where displayed

drop skip_invalidated_bank_accounts option, we are now using
base_category instead.

erp5_accounting, erp5_payment_mean: display currently selected Bank Account even if it is invalidated.

no need to validate them in the test