feat: Support Nutriment modifiers

[g123k]

Hi everyone,

The idea of this PR is to support nutriment modifiers from the JSON.
Here are the different cases:

• - : no value available on the package
• > : more than a value
• < : less than a value
• ~ : approximately this value

For now this is just a draft (tests are missing for example).
It's basically to receive feedback for the implementation.

A JSON example with all values with a -:

        "nutriments": {
            "alcohol_modifier": "-",
            "carbohydrates_modifier": "-",
            "energy-kcal_modifier": "-",
            "energy-kj_modifier": "-",
            "fat_modifier": "-",
            "fiber_modifier": "-",
            "proteins_modifier": "-",
            "salt_modifier": "-",
            "saturated-fat_modifier": "-",
            "sodium_modifier": "-",
            "sugars_modifier": "-"
        },

[monsieurtanuki]

Hi @g123k!

My main remarks:

• we would probably be better off with a breaking change, and from now on use only a Map<String, NutrientValue>, to make it obvious for the developers that they can use potentially modified data with getNutrientValue only
• if instead we keep the old methods (e.g. getValue) as merely "deprecated", the developers will use potentially wrong data. And in that case NutrientValue has no real added value.
• if we could get rid of French spelling it wouldn't hurt ;)

[monsieurtanuki]

• Should be spelled NutrientModifier
• Could implement OffTagged
• Not sure if we need @JsonValue here, which is redundant with the value field
• Would rename field value as modifier

[monsieurtanuki]

• Should be spelled NutrientValue
• But I'm not convinced of the added value of this class.

[monsieurtanuki]

Not sure we need it.

[monsieurtanuki]

Maybe wrong, not sure, depends on the received data:

1. are the value and the modifier merged together into a single String, like 'sugars_100g': '<0.5'
2. or do we get the value in a field and the modifier in another, like 'sugars_100g': 0.5,'sugars_100g_modifier':'<'

If it's (2), the continue is wrong.

[g123k]

I was hesitating between the two solutions : a full breaking change path or not.
But you're probably right, and we should fully remove the old methods.
I will do that, thanks as well for your feedbacks.