[Messenger] New transport.serializer configurations

[nikophil]

Q	A
Branch?	6.3
Bug fix?	no
New feature?	yes
Deprecations?	no
Tickets	Fix 49081 49094
License	MIT
Doc PR	waiting for this PR approval :)

Hello,

here is a proposal for Messenger, in order to improve processing for messages incoming into the app (ie: messages produced by another app) and messages outgoing from the app (ie: messages produced by our app but intended to be consumed by other apps).

Problem with incoming messages: (see 49094)

If messages are incoming in the app under different formats (json, xml, whatever) there is no easy way to customize per transport the serialization process to select which transport will use which format. Another annoyance is that we need to create a custom serializer class to determine in which class we want to deserialize the message.

This PR proposes a new configuration to handle this:

messenger:
    transports:
        transport_for_incoming_messages:
            dsn: 'null://'

            # when used, will use a new class "IncomingMessageSerializer", along with Symfony's serializer
            incoming_message_serializer:
                # one of these ones are required:
                messageClass: App\Some\Message
                messageClassResolver: 'service_id' # should implement a new interface "IncomingMessageClassResolverInterface"

                format: 'json' # defaults on "messenger.serializer.symfony_serializer.format"
                context: {some: context} # if empty, defaults on "messenger.serializer.symfony_serializer.context"

                # this option could be useful when dealing with complex messages which needs specific serializer service
                serializer: 'my_fancy_serializer' # defaults on "@serializer"

Problem with outgoing messages: (see 49081)

Messages which are made to be processed by other apps should be sanitized: stamps and header type must be removed, otherwise they could create errors in other apps (ie: if the message class does not have the same FQCN in both apps, or bus name in sender app which does not exist in receiver app. Both of these cases will trigger errors when processing messages in the receiver app).
Outgoing messages may also be required to have specific format/context, so we must be able to configure format, context and serializer service used.

messenger:
    transports:
        transport_for_outgoing_messages:
            dsn: 'null://'

            # when used, will use a new class "OutgoingMessageSerializer", along with Symfony's serializer
            # all parameters are optional
            outgoing_message_serializer:
                format: 'json' # defaults on "messenger.serializer.symfony_serializer.format"
                context: {some: context} # if empty, defaults on "messenger.serializer.symfony_serializer.context"
                serializer: 'my_fancy_serializer' # defaults on "@serializer"

IMHO, both of these cases are such common, that they should not require boilerplate in userland.

At the end, the PR also provides the ability to add serialization context/format/service per transport, for all other cases:

messenger:
    transports:
        my_transport:
            dsn: 'null://'

            # short notation "serializer: custom_transport_serializer" still works
            serializer:
                # if one of these options are provided, 
				# the transport will use "\Symfony\Component\Messenger\Transport\Serialization\Serializer"
                format: 'json' # defaults on "messenger.serializer.symfony_serializer.format"
                context: {some: context} # if empty, defaults on "messenger.serializer.symfony_serializer.context"
                serializer: 'my_fancy_serializer' # defaults on "@serializer"

                # previous options are incompatible with the following
                serializer_id: custom_transport_serializer

NB: options incoming_message_serializer, outgoing_message_serializer and serializer are incompatible