F refactor retrieve/insert properties

Summary

Move back-end logic from the (abstract) transaction layer to the back-end implementation layer (for MySQL). Effectively, this hides the logic of replacement ids (also known under the misnomer "Domains").

related: https://gitlab.indiscale.com/caosdb/customers/umg_med_inf/management/-/issues/49

Focus

• These code changes must not change the API. Therefore integration tests must not be touched.
• The "big" change was moving code from the InsertEntityProperties class to the MySQLInsertEntityProperties class and changing the place where the response from the MySQL backend is transformed from a list of flat object (former rows) to a deep tree of properties which happens in the MySQLRetrieveProperties class now.
• The ProtoProperty class is now used for those deeply nested properties and also for non-scalar values. That means it is back-end agnostic now and yet we can use it for the caching (while the more complex classes Entity oder Property are not well-suited for caching).
• The DatabaseUtils, as before, contains mostly back-end specific implementations (used by MySQLInsertEntityProperties and MySQLRetrieveProperties). Therefor it moved to the ...implementation.MySQL package. Since the Query classes still need this class here and there we cannot make it package visible yet and it has to stay public.
• Note that the Domain class and the setters and getters for "replacements" of the EntityInterface class have been removed because the replacement is now really contained by the MySQL implementation.
• The new Replacement class is basically the successor of the Domain class

Check List for the Author

Please, prepare your MR for a review. Be sure to write a summary and a focus and create gitlab comments for the reviewer. They should guide the reviewer through the changes, explain your changes and also point out open questions. For further good practices have a look at our review guidelines

• All automated tests pass
• Reference related issues
• Up-to-date CHANGELOG.md (or not necessary)
• Up-to-date JSON schema (or not necessary)
• Appropriate user and developer documentation (or not necessary)
  • How do I use the software? Assume "stupid" users.
  • How do I develop or debug the software? Assume novice developers.
• 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)
• Appropriate user and developer documentation (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.