…ct classes for resource definitions (nicolas-grekas)

This PR was merged into the 7.4 branch.

Discussion
----------

[DependencyInjection] Parse attributes found on abstract classes for resource definitions

| Q             | A
| ------------- | ---
| Branch?       | 7.4
| Bug fix?      | no
| New feature?  | yes
| Deprecations? | no
| Issues        | -
| License       | MIT

This PR improves support for resource definitions by allowing to parse attributes on abstract classes.

This can be useful for PRs like #61563 and #61545, so that the attribute proposed there could be set on abstract classes.

Commits
-------

6571f7b [DependencyInjection] Parse attributes found on abstract classes for resource definitions

…re new serialization attributes for a class (nicolas-grekas)

This PR was merged into the 7.4 branch.

Discussion
----------

[Serializer] Add `#[ExtendsSerializationFor]` to declare new serialization attributes for a class

| Q             | A
| ------------- | ---
| Branch?       | 7.4
| Bug fix?      | no
| New feature?  | yes
| Deprecations? | no
| Issues        | -
| License       | MIT

This PR builds on #61532
It's a sibling of #61545

I propose to add a `#[ExtendsSerializationFor]` attribute that allows adding serialization attributes to another class.
This is typically needed for third party classes. For context, Sylius has a nice doc about this:
https://docs.sylius.com/the-customization-guide/customizing-serialization-of-api

At the moment, the only way to achieve this is by declaring the new attributes in the (hardcoded) `config/serialization/` folder, using either xml or yaml. No attributes.

With this PR, one will be able to define those extra serialization attributes using PHP attributes, set on classes that'd mirror the properties/getters of the targeted class. The compiler pass will ensure that all properties/getters declared in these source classes also exist in the target class. (source = the app's class that declares the new serialization attributes; target = the existing class to add serialization attributes to.)

```php
#[ExtendsSerializationFor(TargetClass::class)]
abstract class SourceClass
{
    #[Groups(['my_app'])]
    #[SerializedName('fullName')]
    public string $name = '';

    #[Groups(['my_app'])]
    public string $email = '';

    #[Groups(['my_app'])]
    #[MaxDepth(2)]
    public Category $category;
}
```

(I made the class abstract because it's not supposed to be instantiated - but it's not mandatory.)

Here are the basics of how this works:

1. During container compilation, classes marked with `#[ExtendsSerializationFor(Target::class)]` are collected and validated: the container checks that members declared on the source exist on the target. If not, a `MappingException` is thrown.
2. The serializer is configured to map the target to its source classes.
3. At runtime, when loading serialization metadata for the target, attributes (groups, serialized names, max depth, etc.) are read from both the target and its mapped source classes and applied accordingly.

Commits
-------

386f949 [Serializer] Add `#[ExtendsSerializationFor]` to declare new serialization attributes for a class

…hods private (xabbuh)

This PR was merged into the 7.4 branch.

Discussion
----------

[Serializer][Validator] make `doLoadClassMetadata()` methods private

| Q             | A
| ------------- | ---
| Branch?       | 7.4
| Bug fix?      | no
| New feature?  | no
| Deprecations? | no
| Issues        |
| License       | MIT

I don't see a good reason to have them callable from the outside. This was probably a mistake in #61545/#61563.

Commits
-------

9653488 make doLoadClassMetadata() methods private