Replace config struct with a config crate

[RedEtherbloom]

Description

Our current config struct is both error-prone and tedious to extend(many getters, non-standard ways of setting defaults).
While not a major concern, it also recomputes a lot, adding 10-50ms to startup(depending on hardware and .taskrc)

Solution

Replace our config struct with an implementation derived from one of the major config crates, like config or comfique.
This would also make the transition to our own config file easier, as we could add it and task _shows output both as sources to the config builder.

Additional context

If possible a config struct behind something like an Arc<Mutex<>> would be ideal, to futureproof both for config reloading and more robust async/multithreading.

[RedEtherbloom]

#520

[kdheepak]

I would like to move taskwarrior-tui configuration to a separate file, either a config.toml or a config.lua file.

I really like the idea of using a config.lua because we can extend the config to support callback functions and allow for more customization in the future. But it may be more work than it is worth.

[RedEtherbloom]

I think sticking to a config.toml for now and adding a config.lua file once we introduce more customability is what we would go for.
Good potential choices for customability may also be cargoscript, although we haven't looked into it yet.

[RedEtherbloom]

https://docs.rs/toml_edit/latest/toml_edit/ may be interesting, as it could allow us to edit the config in place.
This + the ability to potentially reload the config could vastly improve the UX for new-users and make iterating on ones config less tedious.
We still have to look into how to wire it up with an actual config crate though. Maybe we can combine it with config-rs? More of a note to self