Add YAML metadata driver for settings configuration

[Ozu-bezariusu]

Introduce a metadata driver abstraction (following Doctrine ORM's pattern) that allows defining settings metadata in YAML files instead of PHP attributes. This separates the application layer (plain PHP settings classes) from the infrastructure layer (YAML configuration), enabling cleaner domain code.

New components:

• MetadataDriverInterface: contract for loading settings metadata from any source
• AttributeDriver: extracts existing attribute-reading logic from MetadataManager
• YamlDriver: reads settings metadata from YAML mapping files
• ChainDriver: chains multiple drivers, attribute driver takes precedence

The YAML driver is opt-in: configure yaml_mapping_paths in the bundle config and install symfony/yaml. Existing attribute-based configuration is unaffected.

[jbtronics]

Hey,
the separation of metadata retrieval looks interesting.
However i am not really convinced yet how useful it is to separate the PHP code and the metadata.

I mean without metadata the class itself is not really interesting and lacks the relevant infos, and its quite easy to get out of sync between both files.
As far as I perceive it the trend in the symfony community is to go from separate config files to attributes directly in code. And if there are separate files its more PHP than yaml.

I am not per se against offering the option of having it separatetly (while having the attributes as main/preffered way) when it is not too much maintenance effort. But we should discuss these aspects first.

[Ozu-bezariusu]

Hey Jan,

I do agree that attributes should remain the primary and preferred way when there is such a trend, but this PR doesn't mean to change that. Actually it is meant to allow developer to decide in terms of architecture.

Regarding maintenance concern: same trade-off exists with Doctrine XML mapping (and YAML was earlier there as well).

The main point of the PR is MetadataDriverInterface, that separates metadata retrieval from management. We could though keep YamlDriver as an example/reference implementation to, once again, let developers decide on their own. They could implement XML mapping just implementing MetadataDriverInterface.

Thank you!

[jbtronics]

Looks good. Thank you.

I have modified settingsregistry in a way, that all logic is now in the metadata driver (even for attributes) to maintain the metadata driver as single origin of truth.

Also i added an mechanism to easily abstract away the container compile time registration of settings, so that you do not need to mess with compiler passes for each new driver, but instead just need to provide a static method, returning the metadata.

[Ozu-bezariusu]

Thanks, Jan

I do really like how it looks now:
CompileTimeMetadataDriverInterface, moving attribute discovery into AttributeDriver. Appreciate it.

Would you be open to a follow-up PR with some docs on the custom driver contract? Mostly to signal it as a stable extension point people can rely on. Happy to draft it if you do agree.

[jbtronics]

If you wanna write something for it, sure.

Personally im not sure how many people will write its own MetadataDriver, as I wouldnt see too many usecases for that, but more documentation is always good. So feel free.