Configuration: Reduce configuration locations and inheritance

Overview

There are now only two automatic possible configuration lookup locations. Why?:

L1. Looking through (and maintaining) multiple files/locations can be confusing (and a Gotcha!), especially for those new to command line tools
L2. Having multiple locations makes debugging and communication harder. "oh actually, that isn't the right path. Can you check/modify/send me the config at this path ..." (althought the find-and-share can be remedied by having some convenience show me the money commands)

There is now no inheritance. Why?:

I1. It makes the local config self contained, and easier to reason about and compare against.
I2. Reduces the amount of code and bugs around configuration, and the mental processing of user

Callouts

Added a quick hack to allow passing a config file path - this philosophically conflicts with caragols' CLI strategy, but not functionally. And it is in a weird spot.
I decided to continue to keep the logging configuration separate. If people want this in the config, we can add it. But for now, it just makes the startup code more complicated for not much benefit --- how often will people want to change the logging, and of those people, who would greatly benefit from having it modified in a non-global way?

Increase usefulness of outdated config warning. perhaps provide documentation link or command to update
Pydantic models - validation and reduce hardcoded string key accessing (+increase intellisense) for our known config/default (ex: maintenance-info) options - this may be overkill though. With pydantic this would be an extra dependency and we would probably want to keep its version requirements pretty loose to support library users
Helper commands for configuration, like
- creates a copy of default global config in current directory for you to override
- help user update old config files, and compare differences