[Security][SecurityBundle] Add a re-authentication entry point - #66016

Part 3 of the sudo mode stack, on top of #66015.

A denied IS_AUTHENTICATED_RECENTLY currently produces a bare 403, which leaves the user no way back in. This adds a firewall option that starts a fresh authentication instead, and saves the target path so they return where they were:

security:
    firewalls:
        main:
            re_authentication_entry_point: form_login # or a service id

Why an entry point and not an access denied handler

handleAccessDeniedException() is strictly ordered: a token that is not full fledged goes to startAuthentication() and the handler is never consulted; otherwise accessDeniedHandler, elseif errorPage. A handler occupies argument 6, and SecurityExtension fills argument 5 only in the elseif, so shipping this as a handler would make access_denied_url unreachable at both the firewall and the application level. The re-authentication decision belongs next to the isFullFledged branch that already pre-empts both, so that is where it goes.

A new ReAuthenticationRequiredException extends InsufficientAuthenticationException carries the intent to the entry point, which is what lets an OIDC entry point send prompt=login later. It deliberately does not extend AccountStatusException, which startAuthentication() treats as "clear the token".

Matching the attribute exactly, not with in_array()

[AuthenticatedVoter::IS_AUTHENTICATED_RECENTLY] === $exception->getAttributes()

AccessListener decides an access_control rule on all of its roles at once, so a denial of [ROLE_ADMIN, IS_AUTHENTICATED_RECENTLY] does not say which attribute failed. Searching the list would send a user who merely lacks ROLE_ADMIN into a re-authentication that cannot help them, and on a firewall whose login page redirects authenticated users away, into a loop. Pinned by a test.

The reason has to come from the attributes rather than the votes: Vote carries voter, result, reasons and extraData, but not the attribute it voted on, and AuthenticatedVoter's denial reason is the same string for IS_AUTHENTICATED_FULLY and IS_AUTHENTICATED_RECENTLY.

Failure modes handled

• An entry point that throws NotAnEntryPointException falls through to the normal access denied handling, because 403 describes a stale authentication better than the 401 the entry point machinery would otherwise produce.
• The option is refused on a stateless firewall at compile time: there is no session to record when the user authenticated, so IS_AUTHENTICATED_RECENTLY is always denied and re-authentication would loop forever.

Known limitations, for the docs

• setTargetPath() skips unsafe methods, so a denied POST saves no return URL. Guard the GET that renders the confirmation form, not the POST.
• The expression form (allow_if: "is_recently_authenticated()") leaves an Expression in getAttributes() and does not trigger the branch.
• An impersonated session has no auth_time at all, since SwitchUserToken does not copy attributes and SWITCH_USER is a different event.