Handle breaking changes to YANG models

[wkz]

In an AFK discussion, the following question was brought up:

Sooner or later, we will have to make breaking changes to YANG models that will cause confd to reject old configs. How should we handle that?

Some ideas:

• confd should only care about the current YANG models belonging to any given version of Infix.
• We can create special text transformers that translate a valid infix-x.y.z config to a valid infix-x+1.y.z config, these can be simple scripts that run a few jq(1) pipelines.
• The transformers can be stacked as infix evolves to support going from any config version to the present.
• The original config should always be preserved, so that a user can audit the diff.
• The config files need a version field, so that we know the starting point in the transformer stack.

[troglobit]

PR https://github.com/kernelkit/infix/pull/324 shows an alternative/complementary route to take for breaking changes:

1. Mark old setting as deprecated or obsolete (needs planning ahead)
2. Introduce new setting replacement, used only if old setting does not exist

[troglobit]

@wkz unfortunately it appears that sysrepo does not support annotations: sysrepo/sysrepo#2462 The bug report has a few years to it, but this seems to be still the case. so I'll go ahead and add a plain config augment with a discouraging description instead.

[troglobit]

Break out into own model, infix-version.yang