[5.4] Add functional test for issue #130 (DI state across kernel reboots)

[TavoNiievez]

Companion test for Codeception/module-symfony#130.

Background

The issue proposed rebooting the kernel right after each request (instead of lazily, at the start of the next request). That change would actually diverge from pure Symfony: Symfony\Bundle\FrameworkBundle\KernelBrowser::doRequest() reboots lazily before the next request, precisely so the request-handling kernel stays alive for post-request inspection. Rebooting right after a request would destroy that state and break a large number of see*/grab* assertions (session, security token, live services…).

The real need behind the issue — configure a service on the fly and have the next request use it — is already supported in a Symfony-coherent way, without changing the reboot timing:

• persistService() / persistPermanentService() — the configured instance is re-injected into the freshly booted container on the next reboot (isolation is preserved for everything else).
• rebootable_client: false (= Symfony's disableReboot()) + rebootClientKernel() for manual isolation.

What this PR adds

A regression test under IssuesCest that mirrors the issue's exact scenario and proves it is resolved with the default rebootable client:

1. Request /external-api → sees the real response.
2. Grab the ExternalApiStub service, fake its response, persistService(...).
3. Request /external-api again (kernel reboots) → still sees the faked response.

Supporting fixtures: an ExternalApiStub service (public, fakeable), plus a controller + route that echo its state.

No change to codeception/module-symfony is required — this documents and guards the already-correct behaviour.