Refactor configuration retrieval/writing

[micahellison]

Feature Request

Use Case/Motivation

Down the road, we'd like to allow users to modify the config from the command line (#330, #1068) but currently our configuration code is a bit finnicky.

We also currently have a process in our code that is constantly rewriting the config file, when it probably shouldn't be.

And it'd be very nice to support and preserve detailed default comments in the config file (#946).

And, as we come up with new config keys and deprecate old ones, it would be nice to have defaults for various keys that never need to be expressed in the config file, rather than constantly adding a "config stew" of keys.

To resolve this issues, we're probably going to want to:

• Pick out a different YAML parsing library to read the config file
• Create a class that represents config data
  • This class, or the code that reads the config data, should include defaults as necessary (even if the key wasn't found)
• Ensure that all code reading config data uses this new class
• Modify the existing code that writes to the config file

[micahellison]

It looks pydantic could be promising for validating the config file when jrnl first loads.

[micahellison]

For #946 to work using ruamel.yaml, we'll need to deal with two different representations of the configuration:

• the actual YAML contents (including with comments), which can be treated more like a database context
• the config values as read by the rest of jrnl, which can be treated more like a Plain Old Python Object (aka data transfer object)

One of the big innovations of ruamel seems to be around modifying just part of the YAML at once. We could take that approach, or keep loading the whole thing into memory then dumping it back. I don't think the performance implications are going to be significant either way so my impulse is to focus instead on maintainability wherever possible.

[micahellison]

This refactor should also at least leave open the ability to read different versions of the config file, and probably some sort of versioning applied to the default values when they're not in the config file.