[Security] Session concurrency control

| Q             | A
| ------------- | ---
| Bug fix?      | no
| New feature?  | yes
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | #7845
| License       | MIT
| Doc PR        | no

This PR is based on #786 by @paschke. The most important changes from this PR are listed below:

* No change is done in `Symfony\Bundle\SecurityBundle\DependencyInjection\Security\Factory\SecurityFactoryInterface` to maintain BC.
* The SQL for the upsert in `Symfony\Bridge\Doctrine\Security\SessionRegistry\SessionRegistryStorage` is borrowed from `Symfony\Component\HttpFoundation\Session\Storage\Handler\PdoSessionHandler`
* A new `Symfony\Component\Security\Http\Session\CompositeSessionAuthenticationStrategy` class exits to wrap the actual SessionAuthenticationStrategy, and to split the concurrency control in two steps: the first one checks the concurrency, the last one registers the session information in the registry.
* The new configuration parameter `firewalls.secured_area.session_concurrency.error_if_maximum_exceeded` allows you to configure the default behaviour when session concurrency is detected: to avoid a new login, or to expire the oldest sessions.
* The `Symfony\Component\Security\Http\Firewall\ConcurrentSessionListener` is renamed to `Symfony\Component\Security\Http\Firewall\ExpiredSessionListener`
* We have some unit and functional tests now.

Here the variable is called `exceptionIfMaximumExceeded`, which is the same name used by the Spring framework. But previously, `error_if_maximum_exceeded` was used (see https://github.com/symfony/symfony/pull/12009/files#diff-b0ebd53c6c0d79dc95d4c37b00c96552R13)  If they refer to the same functionality, we should use the same name in both cases (I propose to follow the Spring framework naming).