Description:

Messenger Bundle
This PR introduce a new bundle called MessengerBundle which integrates Symfony/Messenger which acts as the main bus and queue engine for Mautic.

How this bundle works?

1. It inject itself as a dependency all the time, I need help to make the injection dynamic. I tried several approaches but all of them would require cleaning the cache. In my opinion we do not need Mautic to send the email directly from memory. let's make use the queue all the time.
2. It uses doctrine (database) as the default queue where it store messages before sending.
3. The bundle uses a single parameter in local.php in format of DNS, this DNS is composed in each plugin that inject itself as a messenger plugin
4. This bundle is extendable to support other queues like Redis, I wrote a plugin for Redis to demo how the code can be used to to inject more transports. I intended to open-source this plugin.
5. There is an env var that we use to define the consumer name. MAUTIC_MESSENGER_CONSUMER_NAME this will change the name of consumer that will listen to the queue and dispatch the messages.
6. The command mautic:email:send has been deleted because of this bundle, and the spool functionality as well.
7. From now on the command to send messages from the queue will be php bin/console messenger:consume

What is missing for this bundle

1. Automated tests
2. Deciding whether we need to inject it all the time or have the option to enable/disable it
3. Manual testing

Email Bundle
In the email bundle we rely on [Symfony/Mailer](https://symfony.com/doc/current/mailer.html) and removed all the references to swiftmailer

What has changed ?

1. All the transports has been removed, because we want them to plugins outside the core of Mautic
2. Mailer is integrated with messenger so emails are queued directly to the database (or your choice of queue).
3. Callbacks classes remained the same but their URLs will be changed depending on the transport name from example amazon_api has been changed to ses+api.
4. There is a single parameter that configure mailer in a format of DSN like this ses+api:username:password@default?region=us-east-1
5. I included SES plugin that will be open-sourced as well.

What is missing for this bundle

1. Automated tests
2. Including other transports as plugins
3. Manual testing

This PR introduce the following improvements:

1. Faster email sending, I tested with SES API and managed to get 3.5X speed increase compared to what we have in M4.
2. Less memory consumption as messenger compacts the emails when they are stored in the queue
3. Storage optimization, with M4 file spool, the disk may get filled with messages pending but with this change the messages will be loaded to redis or database and multiple processes can send at the same time.
4. We were able to run 32 processes to send emails simultaneously
5. This PR will be the door to introduce faster and more lightweight transports
6. We can use the transports that are maintained by Symfony without extra work on our side

Steps to test this PR:

1. Open this PR on Gitpod or pull down for testing locally (see docs on testing PRs here)