[Security] Add a current_user() function to the expression language provider

`ExpressionLanguageProvider` gains a `current_user()` function returning the
authenticated user. Its constructor now accepts an optional authorization
checker, token storage and request stack, so that every function it declares can
be evaluated outside of an authorization expression: each one reads its variables
first and falls back to the services. `is_granted()` and the other three failed
there until now, on the missing `auth_checker` variable.

The variables keep winning over the services, so that `isGrantedForUser()`, which
pushes the token of the user being checked, still answers for that user rather
than for the authenticated one. Compiling stays supported by the instance built
without services, the one `Security\Core\Authorization\ExpressionLanguage`
prepends. The request stack makes the functions throw outside of a request
instead of reporting that nobody is authenticated, which matters for
`#[MapEntity]` in a console command.

SecurityBundle registers the wired instance as
`security.expression_language_provider`. It carries no
`security.expression_language_provider` tag: authorization expressions already
provide the variables that the functions read first, so adding it to
`security.expression_language` would change nothing.

FrameworkBundle registers that service on `validator.expression_language`, so
`ValidatorSecurityExpressionLanguageProvider` goes away, unreleased, and
`#[Assert\Expression]` gains `current_user()` on the way. Its integration test
moves to the component along with the provider it now covers. DoctrineBundle
picks up the same service for `#[MapEntity]` expressions in
doctrine/DoctrineBundle#2280.