Support updating referenced WoT ThingModel minor version for Ditto Things

[thjaeckle]

Currently, the WoT ThingModel is only taken into account when creating new Things in Ditto. In this case, a JSON skeleton of the Thing based on the WoT TM is created.
Over time, a WoT ThingModel might however evolve, e.g. new properties, new actions or new submodels, etc. are added.

Those evolvements can be categorised in:

• non-breaking evolvements (according to Semantic Versioning changes to the MINOR version):
  • only additions to existing functionality without removing existing properties/actions/events
• breaking evolvements (according to Semantic Versioning changes to the MAJOR version)
  • also containing breaking functionality with renaming/removing existing properties/actions/events
  • out of scope for this issue - as this would require e.g. also deleting stuff from things or renaming

In my experience, non-breaking evolvements can happen very regularly, as the (exposed) functionality of IoT devices evolves quickly over time.
For such non-breaking evolvements, Ditto shall provide means to "migrate" existing things to a newer MINOR version of referenced WoT ThingModels.

Concretely, the following steps would have be done when updating the minor version of a WoT ThingModel in a Ditto thing's definition:

• definition of a Thing is modified (either via ModifyDefinition or via MergeThing for the "definition")
• Ditto checks if the "minor" version increased - and only if it did - performs a "migration":
  • resolving all "submodel" versions of the new "minor" thing model
  • update all feature definition fields with the updated "submodel" models
  • potentially adding previously non-yet-existing features in the process
  • for existing features / "submodels" which received a minor update, for each pair of <old model version>,<new model version>:
    • generate JSON skeleton for <old model version>
    • generate JSON skeleton for <new model version>
    • calculate the "diff" as Json Merge Patch from new to old JSON skeleton
    • for all "new added" (non-optional) properties:
      • create the property with the defined default value
      • but only if the Thing does not yet contain a "real" value for the property yet (which could already be sent by the real device - we don't want to overwrite "real" values with default values)

The algorithm might still not be "complete" - but in a nutshell, we have to handle:

• updating Thing attributes with default values for new TM "properties"
• updating Feature properties with default values for new TM "properties"
• updating Feature definitions
• updating the Thing's definition if all was successful
  • TODO: what to do in case of an error?
• and that - all based on a simple update request of a Thing definition