[Validator] Added 'Any' validator

| Q             | A
| ------------- | ---
| Bug fix?      | no
| New feature?  | yes
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | -
| License       | MIT
| Doc PR        | -

The `Any` constraint allows you to re-use existing constraints and is satisfied when at least one of the constraints validated.

### Usecase
You have a form with a field that can either be a number greater than `3`, or match a specific regex.
You could write your own `Validator` class and create your own little `$number > 3`-tests and `preg_match` calls. Or... you might be using an existing Constraint (e.g. `Iban`), and would simply like to also allow a different value to be passed (for instance a normal bank account number).

So how can we combine those constraints to satisfy a given value if **any** of them validates?

Here's where the `AnyValidator` comes in handy. You can pass it an array of constraints that will then be checked during validation. If **any** of them found the value to be valid, the constraint is satisfied (no errors). 

Below is an example of what this would look like in your FormBuilder:
```php
// src/Acme/DemoBundle/Form/Type/MyForm.php
public function buildForm(FormBuilderInterface $builder, array $options)
{
    // ...
    $builder->add(
        'my_example', 
        null,
        array(
            'label'       => 'My example field',
            'constraints' => array(
                new Any(array(
                    new Regex('/here-is-my-regex/'),
                    new GreaterThan(3),
                ),
            ),
        )
    );
    // ...
}
```

The validation message that is used when all constraints failed can be controlled by passing it as a key/value in the `$options` argument. For example: 
```php
// ...
$constraint = new Any(array(
    'constraints' => array(
        new Iban(), 
        new DutchBankAccount()
    ), 
    'message' => 'You must supply either an iban number OR a valid Dutch bank account'
);
// ...
```

Once this PR has reached an acceptable state I will add the necessary docs to complement the changes.

btw, you should not use 2 implementation but rather detect the API version inside a single validator to adapt the logic. See #11587 for the PR switching to this way for existing classes