Add support for a configuration file

[agronholm]

SQLACodegen is getting too many command line options to support comfortably. A configuration file would allow us to support a wide variety of options while keeping the required CLI incantations to a minimum. In particular, it would probably solve the problem presented in the oldest open issue, #25.

The biggest question is, what format to use? I think YAML and TOML are the only reasonable choices. YAML is in widespread use and offers a great end user experience. TOML, on the other hand, has a parser in standard library (3.11), but the standard is not widely used and even its author no longer recommends it. YAML has parsing pitfalls where special values can be interpreted as types other than the string the user probably expected. TOML

TOML pros:

• has a parser in standard library (3.11)
• we could use pyproject.toml to store the configuration

TOML cons:

• relatively new format, not widely used (tooling support isn't quite there yet)
• more verbose for complex structures than YAML
• even its author no longer recommends it

YAML pros:

• in widespread use
• offers a great end user experience

YAML cons:

• always requires an extra dependency
• has parsing pitfalls where special values can be interpreted as types other than the string the user probably expected

[leonarduschen]

Normally, I'd be leaning towards TOML so we'd be able to use pyproject.toml to avoid maintaining an extra config file. I find having configs for tools like mypy, isort, black consolidated together in one file has been a great improvement in quality of life.

However, I feel sqlacodegen is an exception to this rule. Unlike the aforementioned tools which exist throughout the entirity of the project lifetime, I typically only use sqlacodegen when starting a new project using an existing database or during a big refactoring (e.g., replacing tables with declaratives). So in this case, I might even want to keep config for sqlacodegen in a separate file so I can easily place it in .gitignore.

For the above reasons + possible need of more complex configs in the future (e.g., #25), I'm of the opinion that YAML is the better choice. Unless, of course, there have been other usecases of sqlacodegen that I don't know about yet.