[Doctrine] [Bridge] Add a "repository" option to the uniqueEntity validator

| Q             | A
| ------------- | ---
| Bug fix?      | not really
| New feature?  | yes, but debatable
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | No
| Fixed tickets | #12573, #4087
| License       | MIT

See #12573 for more explanations.

I made a pull request for the 2.7 branch, as this is a new feature. But IMO, it's questionable, as it is an easy-pick for older branches. This could easily be merge into 2.3 without any bad behavior.

The new repository option expects an entity path, in order to select its repository.
This allows to use properly the `UniqueEntity` constraint on hierarchical (inheritance) entities, using the root class repository in order to check the uniqueness, and not just the child repository.

Given this inheritance scheme:


`User` ← `Customer`
.‪.…‪…‪ ← `Society`


The code below is now sufficient in order order to check username uniqueness in both `Customer` & `Society` entities, when trying to register a `Customer`.

```php
#ACME\UserBundle\Entity\User.php
/**
 * @ORM\Entity
 *
 * @UniqueEntity(fields="username", repository="ACME\UserBundle\Entity\User")
 *
 */
class User { ... }
```

Not specifiying the repository option will not cause any issue, and keep the same behavior as before.

## Further:  

The above case, IMO, might be the most used one, and it seems perhaps redondant to specify the current class as the repository to use for the constraint. Maybe we could imagine a `current` value for the `repository` option, auto-detecting the class on which the constraint is bound. (feasible ??)

Some other values could be considred in this way:
- `current`: As described above, will detect the exact class on which the constraint was bound, and use its repository.
- `root`: Will search for the top-level entity (User) and automatically use its repository.
- `real`: the current behavior. Is the default value for the repository option (or null).

For 3.0, I think the default value should be `current`.

## Discuss:  

- For now, the `repository` option name is disputable, as it expects an entity path in order to load its repository, and not the repository itself. Should it be renamed ?
- If I define my Repositories as service, would I be able to somehow define a service for this as well ? (suggested by @itar)
`is_subclass_of` or `!is_subclass_of` ?