Let's say the company uses a GS1 nomenclature and a user scans such a
barcode:
`(01)11111111111113(10)xyz(30)40`
It means a product:
- that has the barcode value '11111111111113'
- for the lot 'xyz'
- with a quantity equal to 40

The GS1 nomenclature explains that a lot consists of a prefix `10` and
of up to 20 alphanumeric characters. In the above example, we could
believe that the lot is actually `xyz3040`. To prevent this kind of
issue, the GS1 standards use a special character: the Group Separator
(its hex value is `\x1d` and does not have any visual representation).
So, when reading the barcode of the above value, the barcode reader will
detect the GS between `z` and `3` (so we know that this is the end of
the lot name).

Because GS has no visual representation, the way the GS character is
given by the scanner to the device depends on the scanner itself. For
instance, some barcode readers try to encode GS thanks to its unicode
input (as used on a Windows device): it enters Alt+0+2+9 (i.e., the
unicode value of GS). This is an issue since we filter out all keydown
events with the `Alt` key pressed.

Also, our way to interpret the barcode value depends on the device: on a
desktop device, we listen the events. As explained above, this could be
an issue (for instance with Alt+029). On a mobile device, we let the
barcode reader write in an hidden input and we then extract the written
value. There is also an issue here: the GS is not present in the
extracted string.

For these reasons, some changes are need. The idea is to let the user
lists the ways his barcode readers will encode the GS character (the
scanners often give the possibility to set a value manually.). There is
already a field for this:
https://github.com/odoo/odoo/blob/320025ee630acadd4a5cbd32f425cddee4f81c1e/addons/barcodes_gs1_nomenclature/models/barcode_nomenclature.py#L18-L20

However, this is not correctly working. Suppose we now stop to filter
out the `Alt` keys: in the above example, the scanned value becomes
`011111111111111310xyzAlt0293040`(as you can see, there is an `Alt029`
at the end of the lot). Suppose also that we defined
`gs1_separator_fnc1` with `Alt029`. When parsing the barcode value, we
have:
https://github.com/odoo/odoo/blob/1c0dec6d5813fa81a0fec8668ee13d8036cde5c5/addons/barcodes_gs1_nomenclature/static/src/js/barcode_parser.js#L91-L98
So, when we try to extract the lot name, the values will be:
- barcode: `10xyzAlt0293040`
- regex: `^(10)([!\"%-/0-9:-?A-Z_a-z]{0,20})(?:(Alt029))?`

And here is the issue: `Alt029` will be caught by the second capturing
group of the regex (instead of the third one), so it will be considered
as part of the lot name, we still have an issue => considering the
`Alt`/`Control` keys and defining some values in `gs1_separator_fnc1`
are not enough, we need to parse twice:
- The first parsing is used to convert all occurrences of
`gs1_separator_fnc1` into the hex `\x1d`. Then, it is also used to
remove all useless `Alt`/`Control`/`Shift`.
- The second parsing is the already-existing one and this parser is
already able to catch all `\x1d` as group separators:
https://github.com/odoo/odoo/blob/1c0dec6d5813fa81a0fec8668ee13d8036cde5c5/addons/barcodes_gs1_nomenclature/static/src/js/barcode_parser.js#L90

For the mobile device, it means that the users will have to define a
special character that stands for GS (e.g., `#`), so we will retrieve it
in the input.

OPW-2930873