Refactor the configuration layer

[TeresiaOlsson]

The purpose of this PR is to create a separate configuration layer. This includes:

• Separate the config model classes from the classes which are performing the business logic.
• Add a schema registry to handle validation of dynamic nested pydantic basemodels.
• Add a configuration registry to store and dynamically change the configuration data -> similar to the functionality of the MML AcceleratorObject.

Advantages:

• Better separation of concerns. Separate classes are responsible for validation of the configuration, storing the configuration and performing the business logic.

• Pydantic becomes a more lose dependency. It is no longer used inside the business logic parts of the code but can be separated out to only be used for validation of input data. Nested Pydantic BaseModels now only contain built-in types or other BaseModels which makes it easier to use the functionality of Pydantic to validate nested data and generate json schemas. Arbitrary types in the BaseModel is no longer allowed.

• It becomes possible to make validation optional.

• Users can create objects directly in Python if they want. No configuration file is required if you just want to create a single device and test how it works.

• The schema registry and configuration registry can be used as backends for creating a GUI application to help the users set up the configuration as well as browse and change the existing configuration.

Disadvantages:

• Developers need to specify the required attributes twice, once for the business logic class and once for the schema. Implementing the schema is however optional and is only required if you want to be able to validate the data.

The PR is work in progress and the code is definitely broken at the moment since this affects everywhere.

[TeresiaOlsson]

This PR is starting to get too large and difficult to merge. I will try to separate out the changes required for the schema registry in a separate PR.