Switch Config to singleton design pattern

[olivierdelree]

Closes #197.

We used to have a Config class with a regular __init__ constructor that would result in a new Config object being instantiated for each module that called it.
This PR restructures the class to be static and use the __new__ constructor. The class now keeps track of a single instance that is created with the first __new__ call and is returned with subsequent calls to the constructor. This has the advantage of synchronising the config across the whole application as only one config ever exists at the same time. Additionally, it means that the current syntax does not need to be modified throughout the application as Config() naturally makes use of __new__ alone if no __init__ exists.
This implementation assumes that only one config will ever be necessary for the application. However, if for some reason in the future (e.g., for simultaneous tests), we need multiple configs to exist at once, the class could be made to instead accept a config ID and keep track of a hashmap of configs.

[olivierdelree]

Regarding potentially using a custom config, should we keep track of the config path? Currently, if we load a config from a file, all's well. But if we modify the config and want to save it back to file after changing it, we don't know where the config came from, or even if it came from a custom path rather than the default.
This shouldn't be too much of a problem in most use cases as the users of the app will most likely always start the app from the same place and the config won't change but for debugging and testing, it would be nice to have ways to save and reload the config.
I'll update this PR with some additions for this but I am more than happy sticking to the first commit only if the additions don't appear worth it down the line.

[olivierdelree]

Looking at the currently opened issues, it seems this also somewhat addresses #116.
From this PR, it would become possible to open a custom config and share that with the whole application but it still requires a custom Python script to stand between the user and the application to specify a custom path. This is fine for tests but not necessarily too nice from an end-user point of view. If the changes proposed here seem acceptable, I can open a new PR that uses a basic CLI parser to allow passing a config path from the CLI when starting the app.
Let me know if you think that would be something of interest.

[celefthe]

Very elegant!!

Check the comment re classes importing from object explicitly, otherwise happy to merge

[celefthe]

Yes nice please do remember to add this as you go, and we should also probably create an authors or contributors txt

[celefthe]

Looking at the currently opened issues, it seems this also somewhat addresses #116. From this PR, it would become possible to open a custom config and share that with the whole application but it still requires a custom Python script to stand between the user and the application to specify a custom path. This is fine for tests but not necessarily too nice from an end-user point of view. If the changes proposed here seem acceptable, I can open a new PR that uses a basic CLI parser to allow passing a config path from the CLI when starting the app. Let me know if you think that would be something of interest.

Yeah I don't see why not, sounds like a useful addition and would also allow for easier troubleshooting on-the-fly on an individual device in the event the application doesn't start on account of a misconfiguration / the default settings not playing well on a particular device.

[celefthe]

This implementation assumes that only one config will ever be necessary for the application. However, if for some reason in the future (e.g., for simultaneous tests), we need multiple configs to exist at once, the class could be made to instead accept a config ID and keep track of a hashmap of configs.

I think we can safely assume only one config will ever be necessary. I think baking-in the alternative introduces unnecessary complexity for what is a mild gain for testing imho

[olivierdelree]

Happy to merge if you are!