Make config models into schemas

[TeresiaOlsson]

The purpose of this PR is to separate the config model classes from the classes which are performing the business logic and add separate functionality for validation and handling schemas.

The advantages of this is:

• 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. This makes it possible to separate validation from object creation making it easier to remove the dependency of Pydantic in the future if necessary without having to rewrite the business logic parts of the code.

• It becomes possible to make validation optional. This is required to be able to integrate third-party devices and applications where validation models might not exist. Also for standard pyAML devices and applications it can be useful to be able to turn validation off since there is no need to do it when you know that your configuration has already been validated and validation just takes extra time during loading.

• 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.

• The config models now only have a single purpose: to define the schema that should be used for validation. They are therefore no longer config models and have been renamed as Schema instead to make their purpose more clear for new users/developers.

• Users can create objects directly in Python without having to first create a ConfigModel. They can do things like:

  model = LinearMagnetModel(calibration_factor=-0.0158575, unit='1/m')
  quad = Quadrupole(name='Q3M1D1R',model=model)
  

  which makes it easier for new users to test and play around a bit without having to generate a configuration file and load it. No configuration file feels necessary if you just want to create a single device and test how it works to read the values for it and compare to how you currently might do it with pytango , pyepics etc.

• It becomes easier to implement a registry for schemas that can serve as a backend for creating a GUI application helping the users to set up the 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.

To do:

• Go through the schema base classes and check so the inheritance is consistent everywhere.
• Modify the factory so it can build the objects from the input dict again.
• Add the validator decorator in PR Add a validation decorator #214 and add validation as an optional step in the factory.
• Fix the __repr__ which is currently broken since it relied on Pydantic.
• Clean up the newly added attributes so they are regular attributes or single underscore depending on privacy + add properties where logic is needed for getting/setting.
• Merge modules. After this change some modules can be merged to reduce the number of files and make the code easier to navigate for new developers/users.
• Fix all broken parts and bugs that have been introduced by the refactoring.
• Add a schema registry.