also str representation of unicode character is different.

Now that default cloudooo is updated to LibreOffice 7, this revealed some
problems with percentage values in spreadsheet cells, it was apparently
working by chance on LibreOffice 5.

This improves erp5_ods_style to use `style:style` referencing a
`number:percentage-style` through their `style:data-style-name` attribute.

Because the same thing was missing for dates to follow the input order of
datetime fields, this is also handled at the same time.

We could do something similar to support all input styles of float fields,
so that we support `1 234.5`, `1.234,5` or `1,234.5`, but this is not done
this time.

See merge request nexedi/erp5!1861

 - the test was using wrong attribute and it was using DummyLocalizer,
which breaks the site configuration. Fix the test and use mock
 - fix ods style not to translate untranslatable columns

Page templates have a builtin translation system (with i18n:) and an
"unicode conflict resolver", so it was not necessary to explicitly
convert to unicode on python2 and this simplifies the transition to
python3

This list was to cast the tuple, it can cause an AttributeError("'tuple' object has no attribute 'append'",)
error when this branch is used.

This is really an error code path, so that was unnoticed.

introduce number:date-style for each of the "input_order" supported by
DateTimeField, so that when exported to ODS we have the same input order
as in html.

so that we can test date time fields in listbox columns and listbox stat
method easily.

With libreoffice5, float fields with input style 12.3% were correctly
rendered as percentages without the need of an explicit
number:percentage-style style, but with libreoffice7 it seems required,
without this, a value of 2.05 is rendered as "2" instead of the expected
"205%"

Instead of duplicating the code for the case where a field value is
rendered from a group (left, right etc) of the form and when the field
value is rendered from a listbox editable field, reuse the macro also
for fields from the form groups.

Because fields from the form groups have top and bottom border, we
introduce a new style prefix for these fields: "with_border_".

Implementation note: We don't declare this new field in
Base_getODSSupportedStylePrefixList, because we need to define the cell
properties each time, so defining this dynamically is not really
interesting.

remove useless `field python: editable_fields.get(column_id, None)`
tal:defines, the macro always documented `field` as required and all
callers pass it.

document that `style_prefix` is required