Settings validation

[TjazVracko]

Context

Currently, no validation of settings is supported. It must be implemented in every application separately.
I propose we add an optional validation callback for each setting so that values can be accepted/rejected. If rejected, the previous setting value stays.

Required steps / Implementation details

• add user_settings_add_validator_with_key and user_settings_add_validator_with_id functions to the API.
• add user_settings_validate_with_* as well, so we can validate a value before calling set.
• When setting a setting, call the validator. If the validator rejects the value, the set function should return -EINVAL.
• Decide if the setting should be marked changed or not when validation fails.
• Check how this intersects with the JSON feature.
• Handle validation failures in the shell
• Handle validation failures in the binary protocol - aka return -EINVAL on the appropriate places.
• Handle validation failures in the BT service. Might only require a change in the write handling (add an additional GATT error if validation fails)
• Add a sample demonstrating the validation feature.

The validation callback should probably be something like this:

bool (*validate)(char *key, uint16_t id, void *data, size_t len);

Definition of Done

A validation callback can be registered for each setting which allows the lib user to validate the values before they are set.