Accelerator load functions

[JeanLucPons]

This PR is to discuss and implement Accelerator load functions.
I would prefer to keep the default Accelerator.load() for file but we can discuss.

[gubaidulinvadim]

I also prefer the default load() to have file as an input (yaml/json/toml)

[TeresiaOlsson]

I imagined a solution where the load function understands itself what type to load depending on the input you give. So if you give it a filename it will use the loader for a file automatically. Then in the future if you instead give some database, web server etc it will use the loader for that. Then the loading interface for the user is the same independently of source.

But for now the only option will be a file anyway.

[TeresiaOlsson]

If you want to initialize an Accelerator from a Pydantic basemodel or a dict, it's different. Then instead of using accelerator.load() I think you should be able to create the accelerator object directly. For me the purpose of the load is just to read the config from some external non-python source. Similar to how you in pyAT can load from different sources or create the Lattice object yourself from a list depending on how you prefer to do it.

[TeresiaOlsson]

I'm working on a suggestion for how to do this. So if it's fine, maybe wait a bit with merging this PR until I have had time to finish my suggestion? I think it's anyway mostly me at the moment who wants to be able to have the different options so it's not an urgent PR.

[gubaidulinvadim]

@TeresiaOlsson will your proposal be available before the workshop in February? We need to fix a version / commit to be used at the workshop. I wonder if we should merge this now to give people flexibility in load functions, if you proposal will not be ready soon.

[TeresiaOlsson]

I hope so but my plan is not that it should be merged before the workshop. I'm planning to make a proposal for how to make the configuration layer more modular, add the registry functionality and make it more future proof by not tying pydantic in as tightly as it is now. It will require refactoring so I thought it would be better as a pull request for discussion and work at the hackathon.

It's also connected to the idea of "the ecosystem" which is something else I think we should discuss at the workshop. For example, there might be labs which want to be able to combine pyAML devices, ophyd/ophyd-async devices, devices from other frameworks, from hardware manufacturers etc and use the same configuration layer to initialize all of them and use in applications. I have seen other communities be able to do that and it's very powerful. I think we have the starting point to achieve that but based on the experience of the communities that have got this to work I think we need to discuss how and where we can make things more modular. And potentially also the use of protocols.