F refactor high level api

Summary

This is a new version of the old high level API that was previously contained in apiutils. I completely refactored the structure of the entities, to make use of more up-to-date concepts:

• Usage can be completely offline now (including resolving references), e.g. without a running CaosDB which also allows for comprehensive unit tests.
• Clear separation between resolved and unresolved Entities.
• Transparent yaml serialization and deserialization
• Planned: Transparent support for multi properties.

The main motivation for reactivating and refactoring this module was to facilitate usage of complex entities wihtin simulations and data analysis scripts.

Please also see the included documentation (to be expanded) and lots of unit tests with examples.

Note: This MR includes commits from f-plantuml, f-merge-entities and f-copy-entity, so please review the corresponding MRs first.

Test Environment

There are many unit tests supplied.

Please also test the resolve functions e.g. CaosDBPythonEntity.resolve_references() manually.

Integration tests will be handed in in a later release.

I recommend at least two independent reviewers and this MR is of course still open for discussions and suggestions.

Check List for the Author

• All automated tests pass
• Reference related issues
• Up-to-date CHANGELOG.md (or not necessary)
• Annotations in code (Gitlab comments)
  • Intent of new code
  • Problems with old code
  • Why this implementation?

Check List for the Reviewer

• I understand the intent of this MR
• All automated tests pass
• Up-to-date CHANGELOG.md (or not necessary)
• The test environment setup works and the intended behavior is reproducible in the test environment
• In-code documentation and comments are up-to-date.
• Check: Are there specifications? Are they satisfied?

For further good practices have a look at our review guidelines.

src/doc/high_level_api.org

@@ -119,3 +119,53 @@ Each property stored in a CaosDB record corresponds to:
   - ~description~
   - ~id~
   - ~importance~
+
+
+* Example
+
+The following shows a more complex example taken from a real world use case:
+A numerical experiment is created to simulate cardiac electric dynamics. The physical problem 
+is modelled using the monodomain equation with the local current term given by the Mitchell 
+Schaeffer Model.
+
+The data model for the numerical experiment consists of multiple record types which stores assosciated paremeters:
+- `MonodomainTissueSimulation`
+- `MitchellSchaefferModel`
+- `SpatialExtent2d`
+- `SpatialDimension`
+- `ConstantTimestep`
+- `ConstantDiffusion`
+
+First, the data model will be filled with the parameter values for this specific simulation run. It will be stored in the python variable `MonodomainRecord`. Passing the `MonodomainRecord` through the python functions, the simulation parameters can be easily accessed everywhere in the code when needed.
+
+Records are created by the `create_record` function. Parameter values can be set at record creation and also after creation as python properties of the corresponding record instance. The following example shows how to create a record, how to set the parameter at creation and how to set them as python properties
+
+#+BEGIN_SRC python
+  from caosdb.high_level_api import create_record
+
+  MonodomainRecord = create_record("MonodomainTissueSimulation")
+  MonodomainRecord.LocalModel = create_record("MitchellSchaefferModel")
+  MonodomainRecord.SpatialExtent = create_record(
+       "SpatialExtent2d", spatial_extent_x=100, spatial_extent_y=100)
+  MonodomainRecord.SpatialExtent.cell_sizes = [0.1, 0.1] # parameters can be set as properties
+  MonodomainRecord.SpatialDimension = create_record("SpatialDimension", 
+  num_dim=2)
+
+  MonodomainRecord.TimestepInformation = create_record("ConstantTimestep")
+  MonodomainRecord.TimestepInformation.DeltaT = 0.1
+
+  D = create_record("ConstantDiffusion", diffusion_constant=0.1)
+  MonodomainRecord.DiffusionConstantType = D
+  model = MonodomainRecord.LocalModel
+  model.t_close = 150
+  model.t_open = 120
+  model.t_out = 6
+  model.t_in = 0.3
+  model.v_gate = 0.13
+  model.nvars = 2
+#+END_SRC
+
+At any position in the algorithm you are free to:
+- Convert this model to the standard python API and insert or update the records in a running instance of CaosDB.
+- Serialize this model in the high level API yaml format. This enables the CaosDB crawler to pickup the file and synchronize it with a running instance 
+of CaosDB.