Update src/Symfony/Component/HttpFoundation/Request.php

This makes `getContentType()` work when a regular form is submitted.
[Form] Choice children can be template customized like collection
[Security] made it possible to override the default success/failure handler
[Security] made it possible to override the default success/failure handler (take 2)
[DependencyInjection] made some perf improvements
[Validator] Fixed LegacyValidator when only a constraint is validated
[Validator] Added ConstraintValidator::buildViolation() helper for BC with 2.4 API
feature #9033 [Form] Choice children can be template customized like collection (adrienbrault)

This PR was merged into the 2.6-dev branch.

Discussion
----------

[Form] Choice children can be template customized like collection

| Q             | A
| ------------- | ---
| Bug fix?      | no
| New feature?  | yes
| BC breaks?    | yes?
| Deprecations? | no
| Tests pass?   | No ?
| Fixed tickets |
| License       | MIT
| Doc PR        | None

I wanted to customize the template of a children of a choice field. I learned it was not currently possible, though it is with the collection type. So this should let people be able to customize the template for all the choice children at once.

Ie:

```jinja
{% block _user_colors_entry_widget %}
```

Still have to fix the tests

Commits
-------

4e6b27f [Form] Choice children can be template customized like collection
bug #12031 [Validator] Fixed LegacyValidator when only a constraint is validated (webmozart)

This PR was merged into the 2.5 branch.

Discussion
----------

[Validator] Fixed LegacyValidator when only a constraint is validated

| Q             | A
| ------------- | ---
| Bug fix?      | yes
| New feature?  | no
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | -
| License       | MIT
| Doc PR        | -

The 2.5-BC API is currently broken for the following use case:

```php
$validator->validate($value, $constraint);
```

This is fixed now.

Commits
-------

1d48206 [Validator] Fixed LegacyValidator when only a constraint is validated
bug #12016 [Validator] Added ConstraintValidator::buildViolation() helper for BC with the 2.4 API (webmozart)

This PR was merged into the 2.5 branch.

Discussion
----------

[Validator] Added ConstraintValidator::buildViolation() helper for BC with the 2.4 API

| Q             | A
| ------------- | ---
| Bug fix?      | no
| New feature?  | no
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | -
| License       | MIT
| Doc PR        | -

This PR adds a `buildViolation()` helper method to the base `ConstraintValidator` to remove the API checks (2.4 vs. 2.5) from the constraint validator implementations. Once the 2.4 API is removed, this helper method will be removed as well.

**Todos**

- [x] Backport changes from #12021

Commits
-------

6b0c24a [Validator] Added ConstraintValidator::buildViolation() helper for BC with 2.4 API
feature #11993 [Security] make it possible to override the default success/failure handler (fabpot)

This PR was merged into the 2.6-dev branch.

Discussion
----------

[Security] make it possible to override the default success/failure handler

| Q             | A
| ------------- | ---
| Bug fix?      | no
| New feature?  | yes
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | #5432, #9272, #10417, #11926
| License       | MIT
| Doc PR        | symfony/symfony-docs#4258

Overriding the default success/failure handler of the security firewalls is possible via the `success_handler` and `failure_handler` setting but this approach is not flexible as it does not allow you to get the options/provider key.

To sum up the problem:

* Overriding the default success/failure handler is possible via a service;
* When not overridden, the default success/failure handler gets options and the provider key;
* Those options and the provider key are injected by the factory as they are dynamic (they depend on the firewall and the provider key), so getting those options/provider key is not possible for a custom service that is only configured via the container configuration;
* Extending the default handler does not help as the injection mechanism is only triggered when no custom provider is set;
* Wrapping the default handler is not possible as the service id is dynamic.

... and of course we need to keep BC and make it work for people extending the default handler but also for people just using the interface.

Instead of the current PR, I propose this slightly different approach. It's not perfect, but given the above constraint, I think this is an acceptable trade-of.

So, several use cases:

 * Using the default handler (no change);
 * Using a custom handler that implements `AuthenticationSuccessHandlerInterface` directly and does not need any options (no change);
 * Using a custom handler that needs the options/provider key (that's the new use case this PR supports).

This PR introduces 2 new classes that wrap custom handlers. If those classes define the `setOptions()` and/or `setProviderKey()` methods, they are automatically called with the correct arguments. Yours handler does not need to extend the default handler `DefaultAuthentication*Handler`, but doing so helps as the setters are already defined there.

Commits
-------

810eeaf [Security] made it possible to override the default success/failure handler (take 2)
36116fc [Security] made it possible to override the default success/failure handler
[Debug] Add link to the output of debug function
Merge branch '2.5'

* 2.5:
  [Validator] Added ConstraintValidator::buildViolation() helper for BC with 2.4 API
  [Validator] Fixed LegacyValidator when only a constraint is validated

Conflicts:
	src/Symfony/Component/Form/Extension/Validator/Constraints/FormValidator.php
	src/Symfony/Component/Validator/Constraints/AbstractComparisonValidator.php
	src/Symfony/Component/Validator/Constraints/RangeValidator.php
feature #12036 [Debug] Add link to the output of debug function (lyrixx)

This PR was merged into the 2.6-dev branch.

Discussion
----------

[Debug] Add link to the output of debug function

| Q             | A
| ------------- | ---
| Bug fix?      | no
| New feature?  | yes
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | -
| License       | MIT
| Doc PR        | -

![link](https://cloud.githubusercontent.com/assets/408368/4403994/98f89526-44ab-11e4-8fa8-85b58afb738a.png)
![lin2](https://cloud.githubusercontent.com/assets/408368/4403998/abbabee6-44ab-11e4-9117-f786718dfb37.png)

Commits
-------

dadd2fe [Debug] Add link to the output of debug function
[Config] Allow extra hint in exception message
feature #11453 [Config] Allow extra hint in exception message (WouterJ)

This PR was squashed before being merged into the 2.6-dev branch (closes #11453).

Discussion
----------

[Config] Allow extra hint in exception message

| Q             | A
| ------------- | ---
| Bug fix?      | no
| New feature?  | yes
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | #1666
| License       | MIT
| Doc PR        | symfony/symfony-docs#4047

Commits
-------

3062b3e [Config] Allow extra hint in exception message
[Security] fix typo
minor #12041 [Security] fixed typo in method call (jdreesen)

This PR was merged into the 2.6-dev branch.

Discussion
----------

[Security] fixed typo in method call

| Q             | A
| ------------- | ---
| Fixed tickets | -
| License       | MIT

Commits
-------

1226dc1 [Security] fix typo
feature #7142 [2.3] Update src/Symfony/Component/HttpFoundation/Request.php (datibbaw)

This PR was merged into the 2.6-dev branch.

Discussion
----------

[2.3] Update src/Symfony/Component/HttpFoundation/Request.php

This makes `getContentType()` work when a regular form is submitted. It would return `"form"`

Commits
-------

c81ec4d Update src/Symfony/Component/HttpFoundation/Request.php
Update the Controller to be consistent

We are always using $this->container->get() and now we're using the short-cut sometimes to access to a service.
It could be nice to stay with $this->container->get(), so for those who copy and paste the Controller to create a ControllerUtils, they wont have to change it (in fact neither ControllerUtils::get() nor ControllerUtils::has() exists).
See: http://www.whitewashing.de/2013/06/27/extending_symfony2__controller_utilities.html