Add CSRF tokens to actions rendered as POST forms

[ERuban]

Actions configured with renderAsForm() are submitted as POST requests, but the rendered <form> contains no CSRF token, so there is no way to protect these state-changing actions against CSRF attacks. The built-in delete action already ships its own token (ea-delete); this PR brings the same protection to custom actions.

Changes:

• The forms rendered by the Button component and by dropdown items with renderAsForm now include a hidden token field with a CSRF token (token ID: ea-action).
• Validation is opt-in in the action method (same approach as delete()): $this->isCsrfTokenValid('ea-action', $request->getPayload()->getString('token')). Documented in a new "Validating CSRF Tokens in Custom Actions" section.

Backward compatibility:

• The token is skipped when CSRF protection is disabled ({% guard function csrf_token %}) or when rendering outside a web request with a session (e.g. CLI/email contexts), so nothing breaks in those setups.
• The extra token field in the POST payload is harmless for existing actions that don't validate it.

Tests: component-level rendering tests (token present with a session, absent without a request), assertions in the existing renderAsForm() functional tests, and an end-to-end test with a CSRF-validating action in the test app (empty/invalid token → 400 and no side effect, valid token → action executed).

[ERuban]

Update: rebased on 5.6.0

The rebase surfaced an overlap with the AI skill added in #7813. That skill documents the current behaviour as a rule, anchors it with tests/Functional/Actions/CustomActionCsrfTest, and recommends passing the token through the action URL instead. Since this PR changes the behaviour the rule describes, the skill had to move with it:

• skills/easyadmin/SKILL.md: the rule now describes the hidden token field and
  the ea-action token ID. The two source_not_contains skill-check entries for
  Button.html.twig became source_contains entries covering both templates.
• skills/easyadmin/references/patterns.md: recipe 4 now validates the token from
  the request payload, which drops the CsrfTokenManagerInterface dependency and
  the per-entity token IDs it required.
• tests/Functional/Actions/CustomActionCsrfTest: the two renderAsForm() tests
  now assert the token is present. The delete test is unchanged and still passes
  as written.

Why a form field rather than the URL: the token stays out of the query string,
so it is not exposed through Referer headers, browser history or access logs.
Applications need no CsrfTokenManagerInterface wiring per controller. And a single
ea-action token is generated per page instead of one token per row on index pages.

I'm happy to move the skill changes into a separate commit, or to reword the rule
if you prefer different wording. The behaviour change is the part that needs a
decision; the skill only has to follow whatever you decide.

Full suite green on 5.6.0 (3383 tests), along with php-cs-fixer, twig-cs-fixer and
doctor-rst.