WIP: Config file for theming/customization

[amelenty]

Resolves #745.

General

• [x] Add serialization/deserialization of Config into a config file
• [ ] Add tests for new code logic
• [ ] Add glyphs for palette and separators

Bugs / Improvements

• Right now, the config file is written to config dir directly instead of creating a onefetch subdirectory. I'm still figuring out how to best ensure that a parent dictionary is created if necessary.
• I want to ensure that if the user-supplied config is malformed, onefetch prints a warning about that and uses the default config values. Or would it be better to fail completely instead of showing the info with default options?

Other questions

• cli.rs got a lot longer. I'm thinking of moving config-specific code to a separate file, but that's most of cli.rs. What would be a good way to separate them?
• Which of the config value sources has more priority, the config file or the command line arguments?
  • The way I see it, the user should be able to override any option via command line, regardless of what's in the config file.
  • But there are options where it's not practical. For example, it would make sense if exclude paths from both sources counted. Otherwise, the user would need to write out all the excluded paths in the config if they want to include an extra path.
  • As of right now, for consistency, all bool values are merged basically as an "or" (if it's true in the config file, then the command-line argument doesn't matter), and all other values are completely overwritten. This is obviously not ideal, and I plan to change it, but I'd like to hear your perspective on what I should change it to.
• I feel like there's an easy attribute solution for serializing MyRegex instead of the trait implementation I wrote, but I couldn't think of one.

I'm very new to Rust, so if something I wrote is not idiomatic, I'll be happy to change that if you point it out.