Add barcode encoding support

[TheLastProject]

• Add new barcodeencoding field to database
• Read barcode encoding from pkpass file
• On default, use zxing's GuessEncoding function in StringUtils (this should not use UTF-8 unless needed)
• Allow manually forcing ISO-8859-1 or UTF-8

TODO:

• Fix Catima import/export
• Test test test test test
• Re-read the code over and over, this feels like a mess, may contain bugs :(
• Do another release without this fix

[TheLastProject]

@joserebelo Before I finish this, I have a question for the Gadgetbridge side of this:

The plan is to add a new barcodeEncoding field, which defaults to auto (null) if it is not set, unless a pkpass file explicitly sets it. When it is set to "auto", Catima will ask zxing to guess if it should use UTF-8 or not.

What would be the best behaviour for the ContentProvider update?

1. I'm planning to bump the minor version, as adding a new field is not incompatible
2. For the barcodeEncoding field in the ContentProvider, should it return null, just like it does in the database, or should it return the "guessed" encoding that Catima would use to display, so Gadgetbridge doesn't have to guess (but technically has "incorrect" data, as it's null in the database)?

Edit: With regards to 2, I think it makes most sense for the ContentProvider to give the simplest usable data to draw a card, instead of the exactly correct info. If full export-import compat is desired, the exporter seems more sensible to use anyway. So, barcodeEncoding would give whatever Catima would be using, guessed or not, but never null.