[Messenger] Add DispatchOnFailureStamp to dispatch a message when another one fails - #65917

Stacked on #65903, which has to be merged first: the diff shows both until then.

A message can now declare what to dispatch when it fails for good:

$bus->dispatch(new ProcessPodcast($id), [
    new ChainStamp(new OptimizePodcast($id), new ReleasePodcast($id)),
    new DispatchOnFailureStamp(new PodcastFailed($id)),
]);

This is the "catch" that #50462 asked for, without serializing a closure: the failure hook is a message, and the failed message plus the error travel with it. The hook belongs to the message that can fail, not to the chain, so it is just as useful on a single message ("notify when this import fails"); ChainMiddleware copies it onto each next step, so whichever step breaks fires it once.

When it fires

"For good" means after the retries:

• In a worker, when WorkerMessageFailedEvent reports that the message will not be retried (DispatchOnFailureListener, priority 0, between the retry listener and the failure-transport listener).
• In a synchronous dispatch, when handling throws (DispatchOnFailureMiddleware, at the end of the default before middleware so that it wraps doctrine_transaction: the failure message is dispatched after the rollback). The same middleware fires when a sync:// transport with a failure transport ([Messenger] Add retry and failure transport support to the sync transport #65902) sends the message there instead of throwing, which it detects from the SentToFailureTransportStamp on the returned envelope.
• A message that is only sent to a transport does not fire anything at send time.

A nested synchronous dispatch inside a worker handler has no retries of its own, so its failure fires on every attempt of the outer message.

What is dispatched

Envelope::wrap($failureMessage) with a FailedMessageStamp holding the message that failed, the ErrorDetailsStamp of the failure, and the BusNameStamp of the failed message so that the same bus handles it. With #65899, a handler reads both by type-hinting them:

public function __invoke(PodcastFailed $message, FailedMessageStamp $failed, ErrorDetailsStamp $error): void

The failure message carries no DispatchOnFailureStamp of its own, so a failing failure message does not loop.

Public API

• Symfony\Component\Messenger\Stamp\DispatchOnFailureStamp(object $message)
• Symfony\Component\Messenger\Stamp\FailedMessageStamp(object $message)
• Symfony\Component\Messenger\EventListener\DispatchOnFailureListener
• Symfony\Component\Messenger\Middleware\DispatchOnFailureMiddleware
• FrameworkBundle registers both, with dispatch_on_failure in the default middleware stack (guarded for older Messenger versions).

Checks

• ./phpunit src/Symfony/Component/Messenger/Tests and ./phpunit src/Symfony/Bundle/FrameworkBundle/Tests: green (usual missing-server skips).
• Revert-verified: the new tests fail without the stamps, listener and middleware; the bundle tests fail without the wiring.

Documentation

• The stamp, the three firing points and the "after retries" rule.
• What the failure message receives, and the stamp arguments example.
• The nested-synchronous-dispatch caveat.
• Serializer note: the stamps carry message objects, so transports using the Symfony serializer need normalizers for them, as with ChainStamp and RedispatchMessage.