fix: keep PHP running until Caddy finishes graceful shutdown

[nesl247]

Fixes #2644.

Caddy stops its apps without dependency ordering. Calling frankenphp.Shutdown() from FrankenPHPApp.Stop() can therefore stop PHP while the HTTP app is still accepting requests during shutdown_delay, producing HTTP 500 responses.

Register a single process-global caddy.OnExit callback so PHP stays available until all Caddy apps have stopped, including the HTTP shutdown delay and in-flight request draining. Keep the existing reload shutdown path unchanged.

Add a process-level regression to the existing Linux test workflow, using the CLI it already builds. Five fresh processes exercise the unordered stop path. The test verifies PHP responses during the shutdown delay, an in-flight response spanning listener closure, actual PHP teardown, and clean process exit. A bounded release handshake avoids waiting for a fixed long-running request.

Validated against current main (daead870980d2aba0c2df76cbea880b5a608ff0b) on Linux ARM64 with PHP 8.5.9 and Go 1.27.1:

• The regression passes with this change and fails on unpatched main after SIGTERM.
• The existing reload_test.sh integration check passes.
• Go formatting, Bash syntax, ShellCheck, and actionlint pass.

The full PHP-version matrix and worker-mode shutdown were not run locally. The regression is wired into the existing PHP 8.2–8.5 Linux jobs. Feedback on the process-exit lifecycle hook is welcome.

[AlliBalliBaba]

Makes sense 👍 . Could you maybe also test that a worker script is still able to do graceful shutdown, eg:

#  worker.php
while(frankenphp_handle_request($handler)){
}

# Make sure this code here still runs in a test, for example by creating a temp file
shutdownlogic();