Allow to configure user preferences with a configuration file

[Jackenmen]

Description

Fixes #37

Draft because this still needs tests, testing, and documentation (documentation probably won't be added here until this solution is accepted).
The proposed solution for storing user preferences was not approved by anyone either so that might still change too if the maintainers don't agree with my proposal.

How does this work?

Now onto how this is supposed to work... User can add a configuration file at ~/.config/cherry_picker/preferences.toml which looks like this:

[global]
upstream_remote = "the_real_deal"
pr_remote = "mine"
push = false
auto_pr = false

[global.--continue]
push = true

[local."/home/jack/CPython"]
upstream_remote = "python"

[local."/home/jack/CPython".--continue]
auto_pr = true

Preferences override themselves in this order (the last on the list has the highest priority):

1. Global configuration
2. Global configuration for --continue
3. Local configuration
4. Local configuration for --continue
5. Arguments passed in CLI

// It might perhaps make more sense to swap 2 with 3 but this order was just how I ended up implementing it so I'm just leaving it as is until I get feedback on this :)

Other notes

In issue #37, I said:

The most obvious solution seems to be using git config since it supports both global and local user configuration already, it is used by cherry-picker already, and therefore should be relatively straightforward.

But I figured that making a TOML file is actually easier to implement and maybe faster? Using git config would require either using a lot of subprocess calls to get all the configuration or parsing the output of git config --local --list, and its nesting support is limited to 3 levels, i.e.:

cherry-picker-preferences.global.upstream_remote=true

which might be fine but is definitely limiting.

[Jackenmen]

Pinging @gpshead as the author of #4 and @markshannon as the author of #19 since I imagine you may both have some interest in this feature due to its practicality over specifying those options through CLI flags.

If you have anything to share on the solution shown here (as described in the PR description - the code is mostly inconsequential and is not covered by tests anyway) then I'd very much appreciate it to know, if this is the right direction for it. When I originally made this (it's been 3 years ago apparently, time flies 😄), I delayed completing the PR with test coverage and such since I had absolutely no clue if this would be accepted but I'd been reminded last week that it still exists so trying to move this forward.