…ss against unique entity constraint (wkania)

This PR was merged into the 7.1 branch.

Discussion
----------

[DoctrineBridge][Validator] Allow validating every class against unique entity constraint

| Q             | A
| ------------- | ---
| Branch?       | 7.x <!-- see below -->
| Bug fix?      | no
| New feature?  | yes <!-- pleasedate src/**/CHANGELOG.md files -->
| Deprecations? | no <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tickets       | Fix #22592
| License       | MIT
| Doc PR        | symfony/symfony-docs#14458 <!-- required for new features -->

Yet another try to allow validating every class against unique entity constraint.
Based on the knowledge from issue #22592 and pull request #24974.

This constraint doesn’t provide any protection against race conditions, which is enough in most cases. You can always try-catch flush method. Let's not talk about this problem.

Current state:
- can be applied only to an entity,
- support entity inheritance,
- can validate unique combinations of multiple fields,
- meaningful errors related to entities,
- is valid during an update, when the only matched entity is the same as the entity being validated

New state:
- preserve the current state,
- all old tests pass (no changes in them),
- no breaking changes,
- can be applied to any class (like DTO),
- can map object fields to entity fields (optional),
- when the object update some entity, there is an option to provide the identifier field names to match that entity (optional)

Examples:
1. DTO adds a new entity.
```
namespace App\Message;

use Symfony\Bridge\Doctrine\Validator\Constraints\UniqueEntity;

/**
 * `@UniqueEntity`(fields={"name"}, entityClass="App\Entity\User")
 */
class HireAnEmployee
{
    public $name;

    public function __construct($name)
    {
        $this->name = $name;
    }
}
```

2. DTO adds a new entity, but the name of the field in the entity is different.
```
namespace App\Message;

use Symfony\Bridge\Doctrine\Validator\Constraints\UniqueEntity;

/**
 * `@UniqueEntity`(fields={"name": "username"}, entityClass="App\Entity\User")
 */
class HireAnEmployee
{
    public $name;

    public function __construct($name)
    {
        $this->name = $name;
    }
}
```

3. DTO updates an entity.
```
namespace App\Message;

use Symfony\Bridge\Doctrine\Validator\Constraints\UniqueEntity;

/**
 * `@UniqueEntity`(fields={"name"}, entityClass="App\Entity\User", identifierFieldNames={"uid": "id"})
 */
class UpdateEmployeeProfile
{
    public $uid;
    public $name;

    public function __construct($uid, $name)
    {
        $this->uid = $uid;
        $this->name = $name;
    }
}
```

Commits
-------

adb9afa [DoctrineBridge][Validator] Allow validating every class against unique entity constraint

…ss against unique entity constraint (wkania)

This PR was merged into the 7.1 branch.

Discussion
----------

[DoctrineBridge][Validator] Allow validating every class against unique entity constraint

| Q             | A
| ------------- | ---
| Branch?       | 7.x <!-- see below -->
| Bug fix?      | no
| New feature?  | yes <!-- pleasedate src/**/CHANGELOG.md files -->
| Deprecations? | no <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tickets       | Fix #22592
| License       | MIT
| Doc PR        | symfony/symfony-docs#14458 <!-- required for new features -->

Yet another try to allow validating every class against unique entity constraint.
Based on the knowledge from issue symfony/symfony#22592 and pull request symfony/symfony#24974.

This constraint doesn’t provide any protection against race conditions, which is enough in most cases. You can always try-catch flush method. Let's not talk about this problem.

Current state:
- can be applied only to an entity,
- support entity inheritance,
- can validate unique combinations of multiple fields,
- meaningful errors related to entities,
- is valid during an update, when the only matched entity is the same as the entity being validated

New state:
- preserve the current state,
- all old tests pass (no changes in them),
- no breaking changes,
- can be applied to any class (like DTO),
- can map object fields to entity fields (optional),
- when the object update some entity, there is an option to provide the identifier field names to match that entity (optional)

Examples:
1. DTO adds a new entity.
```
namespace App\Message;

use Symfony\Bridge\Doctrine\Validator\Constraints\UniqueEntity;

/**
 * `@UniqueEntity`(fields={"name"}, entityClass="App\Entity\User")
 */
class HireAnEmployee
{
    public $name;

    public function __construct($name)
    {
        $this->name = $name;
    }
}
```

2. DTO adds a new entity, but the name of the field in the entity is different.
```
namespace App\Message;

use Symfony\Bridge\Doctrine\Validator\Constraints\UniqueEntity;

/**
 * `@UniqueEntity`(fields={"name": "username"}, entityClass="App\Entity\User")
 */
class HireAnEmployee
{
    public $name;

    public function __construct($name)
    {
        $this->name = $name;
    }
}
```

3. DTO updates an entity.
```
namespace App\Message;

use Symfony\Bridge\Doctrine\Validator\Constraints\UniqueEntity;

/**
 * `@UniqueEntity`(fields={"name"}, entityClass="App\Entity\User", identifierFieldNames={"uid": "id"})
 */
class UpdateEmployeeProfile
{
    public $uid;
    public $name;

    public function __construct($uid, $name)
    {
        $this->uid = $uid;
        $this->name = $name;
    }
}
```

Commits
-------

adb9afa4a5 [DoctrineBridge][Validator] Allow validating every class against unique entity constraint