This pull request adds a new configuration option comparator to the UniqueEntity constraint. The value must be a callable and works instead of identifierFieldNames. The callback, if supplied, is called instead of working through identifierFieldNames, to establish equality between the found entity and the data on the validated object.
This allows custom behavior in those edge-cases where the default equality check after stringification is not enough.

The following is an example of how this works:

#[UniqueEntity(
    fields: ['locale', 'urlAlias'],
    entityClass: EntityTranslation::class,
    // `identifierFieldNames` cannot be used, as, even though the `root` entity
    // would be found, the equality check of `rootId === (string) root` would fail.
    // identifierFieldNames: [
    //     'rootId' => 'root',
    //     'locale' => 'locale',
    // ],
    // instead a `comparator` can be supplied to handle the edge-case:
    comparator: [UpdateEntityTranslationFormData::class, 'compare']
)]
final class UpdateEntityTranslationFormData
{
    public function __construct(
        public readonly Uuid $rootId,

        public readonly ValueObject\Locale $locale,

        #[NotBlank]
        public ?string $name = null,

        #[NotBlank]
        public ?string $urlAlias = null,
    ) {}

    public static function compare(self $value, EntityTranslation $foundEntity): bool
    {
        return $foundEntity->getRoot()->getId()->equals($value->rootId)
            && $foundEntity->getLocale()->equals($value->locale);
    }
}

Without such functionality, one currently has two options:

1. Assign the "full" entity to the DTO, instead of just the id.
2. Have that entity implement \Stringable.

Both are problematic in some cases:

• Solution 1. is not a workable option if one deals with DTOs that should be serializable (for example CQRS commands)
• Solution 2. seems like a hack and issn't really semantic in most cases. Why should an entity be stringable to its id?

Todos:

• probably add more tests
• submit changes to the documentation
• add entry to CHANGELOG
• gather feedback for my changes

This being my first contribution I'm aware that I probably missed a few guidelines - though I tried to follow https://symfony.com/doc/current/contributing/code/pull_requests.html closely. Please don't hesitate to point those out, or if this functionality is in general not wanted!