I'm submitting this PR for the record, because I didn't convince myself it's worth pursuing.

Attributes apart, validation constraints can be declared using dedicated YAML or XML files.
For bundles, those files should be put in predetermined locations.
For apps, there's the framework.validation.mapping.paths config options to list them, and there is the config/validator/ folder that's hardcoded.

In #61545, we added support for configuration via attributes, thanks to #[ExtendsValidationFor].

And I then wondered: what about using plain semantic configuration for apps? That'd be better than the current alternatives, and might be more boring (in a good way) than the new attribute?
That's what this PR achieves, kind of.

framework:
    validation:
        mapping:
            metadata:
                App\MyClass:
                    constraints: [...]
                    properties:
                        someProp: [...]
[...]

BUT, I hit a wall: the structure under metadata is recursive: constraints can list other constraints as options, recursively.
And this is not nicely described using the Config component.
Which means in the end the envisioned DX is going to be poor, because of the lack of descriptive info that'd be required for nice IDE support.

I'm still submitting as food for thoughts.

TL;DR: attributes FTW :)

PS: the same chain of thoughts can be applied to serializer's metadata, related to #61563. There, I don't think the "recursive" argument applies. Yet, we should support both Validator and Serializer if we go this way IMHO. It'd be inconsistent otherwise.