[OptionsResolver] Validate options before normalization

| Q             | A
| ------------- | ---
| Bug fix?      | yes
| New feature?  | no
| BC breaks?    | yes
| Deprecations? | yes
| Tests pass?   | yes
| Fixed tickets | #4500, #10616
| License       | MIT
| Doc PR        | symfony/symfony-docs#4159

Previously, the options weren't validated before the normalizers were called. As a result, the normalizers had to perform validation again:

```php
$resolver->setAllowedTypes('choices', 'array');
$resolver->setNormalizers('choices', function (Options $options, $value) {
    array_merge($options['choices'], ...);
});

// fatal error
$resolver->resolve(array('choices' => 'foobar'));
```

This is fixed now.

After the fix, the `Options` class turned out to be doing everything that `OptionsConfig`/`OptionsResolver` were responsible for previously. Therefore I removed `OptionsConfig` again (introduced in 2.6).

```php
$defaults = new Options(array(
    'choices' => array(),
));
$defaults['class'] = null;
$defaults->setRequired('em');

$options = $defaults->resolve($options);

// Form component example (3.0)
public function setDefaultOptions(Options $options) {
    $options['choices'] = array();
    $options->setRequired('em');
}
```

**BC Breaks**

When using OptionsResolver, instances of the Options class were only exposed to the user within lazy option/normalizer closures. The Iterator interface and the `all()` method did not work there, since they resulted in cyclic dependency exceptions. Thus I removed both.

I also made the `get()` method stricter to be *only* usable within those closures. Before, `get()` was practically only used in those closures, but could theoretically be also accessed outside of that closure. The benefit of this change is that we can implement nested options quite easily in 2.7+.

Both breaks may require people who used the Options class independent of OptionsResolver to adapt their code. However, I don't think there's many (if any) people who did that.

**Deprecations**

OptionsResolver and OptionsResolverInterface were deprecated and will be removed in 3.0. The Options class is now sufficient to configure and resolve options.

The `Options::overload()` method was also deprecated, since its functionality was merged into `set()`.

**Todo**

- [x] Fix PHPDoc
- [x] Adapt CHANGELOG/UPGRADE
- [ ] Adapt documentation
- [x] Deprecate OptionsResolver[Interface]
It is - see the parameter validation down below. Your argument however is very valid and probably the reason why we used `instanceof \Closure` <= 2.5. I'll revert this.