Summary

This PR factors out mpremote's configuration code into a separate file, and adds the ability to specify that configuration from two other sources: environment variables with the MPREMOTE_ prefix, and/or a dotenv-style configuration file called .mpremote in the user's current directory or one of its parents.

My own motivation for wanting environment-variable control here is ease of automation. In heavily-scripted and especially containerized environments, environment variables are generally easier to work with than configuration files. This will help pave the way for e.g. a future CI/CD task for running the mpremote test suite.

The dotenv configuration mechanism is another common configuration method I found while researching existing python libraries for combining and dispatching to available file-based and environment-variable-based configuration methods. I ended up not finding a tool that could process the MPREMOTE_ and MPREMOTE_CMD_ environment-variable prefixes together the way I'd have liked, but I had the dotenv-style loader working already by that point. It adds a convenient way to specify project-specific mpremote configurations to be automatically used when running mpremote in the context of that specific project.

This was inspired by discussion on #17485, and also incorporates a not-entirely-trivial rebase of #9573 to include @Josverl's fixes to the current config.py issues on Windows.

Testing

Not yet done; we're at least at "works on my machine", but I've not yet gone through testing every combinations of configuration sources across multiple applicable environments.

Part of testing this will also need to be ensuring that all available settings are tested, to make sure the testing process has been sensitive to e.g. a need to add some sort of explicit type conversion processing (to the environment-variable loading, or at the site where the relevant config item is used). Since I'll have to go through that anyway I'll also make sure all of those options have documentation.

Trade-offs and Alternatives

More opinionated philosophies like The Twelve-Factor App suggest that environment variables should be the only configuration mechanism. Some of its reasoning in favor of environment variables might be worth reading, but I don't agree with the conclusion that the current config.py mechanism ought to be dropped.

It might still be better to drop the dotenv-style, to avoid proliferating too many ways a user could get tangled in stupid "where even is the damn config file" style headaches, and avoid an obligation to maintain support for it; though I think the usability it adds outweighs that.