feat(BarcodeManualInputDialog): Smarter dialog, with products suggestions

[TTalex]

What

• When entering prices by typing barcodes, it's quite common to mistype or misread one number, sometimes because of proof image quality (differences between 0, 8, 6 and 9 are often hard to tell).
• Before this PR, one would have to submit the barcode to realize that it was invalid, delete the added product/price and re-type the barcode, without knowing which number was wrong
• For EAN13, the check digit allows for quick verification of barcode validity
• It is then feasible for invalid barcodes to go through every digit, replacing it with another digit, and testing again for validity
• This process gives us a list of valid "adjacent" barcodes (usually less than 10), that can be sent to the API for verification
• Finally, all fetched products can be displayed for users to choose what they actually meant, clicking on a product uses its barcode instead of the invalid one

Screenshot

When a valid EAN13 is entered, we might as well display the product, for confirmation

When an invalid EAN13 is entered, we display alternatives (here the last digit was mistyped)

Users are still allowed to submit invalid EAN13 barcodes, when no alternatives are found

Everything is computed on the fly, as soon as the barcode reaches 13 digits

barcodedialog.mp4

Notes

• Non-EAN13 barcodes display the usual submit form
• The brute force algorithm finding alternatives is pretty dumb, if two digits are wrong it yields no results
• The product API does not yet allow multiple barcode search. This PR thus calls the API once per alternative, which can be a bit heavy on resources
• This PR makes the BarcodeManualInputDialog quite a complex component, when it was a very simple one beforehand. Not sure how refactoring it could help.

[TTalex]

Note: a simpler version of this PR was implemented in #1108

[raphodn]

Note: a simpler version of this PR was implemented in #1108

Ah sorry I missed this PR..

• indeed now we have the product card confirmation step so it avoids the back & forth between the price form & the barcode modal
• I also plan to add a simple "clear" button
• I've thought a bit about this barcode search for the cases where the price tag isn't 100% readable, I'd rather have a dedicated discussion together, see this issue for instance where we could leverage the search-a-licious API : Allow complex filtering on the code (startswith, endswith, contains, regex)  search-a-licious#242