feat: yaml config provider

[zilto]

Solves #4345 (and #1596). It expands on previous work that allowed custom config provider.

Changes

There are a lot of files and lines of code changes, but it's inflated by .yaml test cases.

The main changes:

• move logic of the toml config provider to a base class SettingsDocProvider
• keep read/write logic in toml and yaml specific classes

Future work

• update the docs to make more mentions of config.yaml and secrets.yaml
• ensure this is supported by dlthub
• ensure the dltHub AI Harness handles .yaml files properly (e.g., MCP tool to read values, mentions in skills)

[rudolfix]

A few things before full review:

• I'd prune providers that get into initial provider list to declutter exception messages (see comments)
• I'd whitelist yaml extensions in ConfigurationFileSelector to start sending this to runtime. enabling runtime to pass through yaml profiles is separate (right now yaml files will be pruned), but not hard
• tools to redact and update config/secret files that agents are using will need to be rewritten. right now they handle toml only. also rewriting a yaml path will need some kind of convention. we'll need to maybe switch to yaml parser that preserves comments and whitespaces (we were using it in dlthub)
• there are very long module and function docstrings. those should be split and converted into comments. right now they are too sloppy. you can ask claude to apply rules from @docstrings.md or or try /review-vocabulary (which is based on Boeing simple simple English) and see what happens

[rudolfix]

here I'd remove yaml providers that do not have any locations present from the list of providers below. otherwise they will be reported in configuration errors as empty providers without files. we can be smarter and also prune tomls if there are no locations defined (for both config and secrets)