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

This was set to 1.234,5 but erp5_ods_style does not support this style
for now, so set it to a supported value for now so that we can progress
with the testing of erp5_ods_style.

Add a listbox with a figure editable field and a percentage editable
field. These fields all have TALES to set precision from "precision"
request key.

See merge request nexedi/erp5!1846

See merge request nexedi/erp5!1863

See merge request nexedi/erp5!1848

- landing page
- dispatch uses opml-sync parameters
- keeps backward compatibility

py2/py3: import InstanceDict from DocumentTemplate._DocumentTemplate instead of deprecated DocumentTemplate.DT_Util.

use urlsplit instead, prepending '//' like discussed in https://bugs.python.org/issue27485#msg270215

fixes errors on python3, File needs bytes

This not closed comment tag was probably a problem for Chameleon, this
is from a commit from Aurélien in 2021, adjusted by Jérome in 2023 (to
actually remove the code that were commented out, not just removing the
comment and leaving the code)

New cloudooo uses text/csv as mimetype for CSV, which is correct, but this revealed issues in ERP5:
 - ERP5 did not detect text/csv for csv extensions
 - downloading a file with content type text/csv caused an error

See merge request nexedi/erp5!1859

See merge request nexedi/erp5!1860

  in addition to None, id can be an empty list on this case

See merge request nexedi/erp5!1858

DownloadableMixin uses mimetypes_registry to guess an extension from
the mimetype, but this was wrong when the entry in mimetype only defines
globs, an error like this was raised:

      Module erp5.component.mixin.erp5_version.DownloadableMixin, line 143, in index_html
        output_format = mimetype_object.globs.strip('*.')
    AttributeError: 'list' object has no attribute 'strip'

Also blindly apply the same fix in OOoTemplate, as it used the same
problematic pattern.

we use to have two entries for csv:

  - text/comma-separated-values
     - mimes: ["text/comma-separated-values"]
     - extensions: ["csv"]
     - globs: []
  - CSV document
     - mimes: ["text/csv", "text/x-comma-separated-values", "text/x-csv"]
     - extensions: []
     - globs: ["*.csv"]

but text/comma-separated-values does not really exist, rfc4180 recommends
text/csv.

The problem with this configuration is that when ERP5 picks a mime type
for csv extension, it uses text/comma-separated-values, as this one has
extensions set.

Change the configuration to delete "text/comma-separated-values" and keep
everything in "CSV document":

  - CSV document
     - mimes: ["text/csv", "text/x-comma-separated-values", "text/x-csv", "text/comma-separated-values"]
     - extensions: ["csv"]
     - globs: ["*.csv"]

The previous pattern of using click and then pause is fragile and seems
to be the cause for test failures.

Instead of disabling in javascript, which cause the button to be visible
for a few milliseconds, disable directly in the HTML file.

Do not hide "document properties", because it can be useful and it does
not hurt and "edit images" because we don't hide the buttons to edit
annotations either, so this is consistent.

The setter does this already so no change is expected, but these are API
misuses and they just look wrong.

Also, modernise syntax a bit.