[Validator] Added error codes to all constraints with multiple error causes

| Q             | A
| ------------- | ---
| Bug fix?      | no
| New feature?  | yes
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | #7276
| License       | MIT
| Doc PR        | TODO

This PR depends on #12015 and #12016 being merged first. However, a few changes in 52cb7df first must be backported to #12016.

This PR introduces error codes for all constraints with multiple error paths. This lets you determine what exactly the reason was that a constraint failed:

```php
$validator = Validation::createValidator();

$violations = $validator->validate('0-4X19-92619812', new Isbn());

foreach ($violations as $violation) {
    var_dump($violation->getCode());
    // => int(3)
    var_dump(Isbn::getErrorName($violation->getCode()));
    // => string(24) "ERROR_INVALID_CHARACTERS"
    var_dump($violation->getConstraint()->getErrorName($violation->getCode()));
    // => string(24) "ERROR_INVALID_CHARACTERS"
}
```

The `getErrorName()` method is especially helpful for REST APIs, where you can return both an error code and a description of that error now.

**Todos**

- [x] Backport a few structural changes to #12016
- [x] Update constraints outside of the Validator component
- [x] Rebase on master (after merging #12015 and #12016)
This will cause issues in the form binding, as it checks for ``$allowNonSynchronized = Form::ERROR_NOT_SYNCHRONIZED === $violation->getCode();``, and ``Form::ERROR_NOT_SYNCHRONIZED`` is ``1`` as well.

However, we probably need to check the violation constraint instead to ensure it is a Form constraint (we cannot be sure that the whole ecosystem will never reuse the value ``1``)