Use traits for methods that belong to the public API

[TavoNiievez]

This is the directory structure proposed by this PR:

Why should we make this change?

1. Because it increases cohesion and pseudo-reduce coupling, the methods that use a specific service or collector are grouped and it is easy to identify them, to know how many and which there are and which framework classes they use.
2. Because if it is not done, over time, inevitably the Symfony.php module file will grow so much that it will become colossal, which will make it difficult to navigate and, above all, its maintenance. (It was already on the 1629 lines, hopefully, it will not reach 2077.)
3. This does not create any BC and can lay the foundation for the module to continue to grow and improve in a healthy way.

Did you randomly make up that structure and those names for the traits?

No, it is based on Symfony's own structure.

This will break git history, stop it!

Luckily, it will not, in this PR the public methods are simply removed from the main file of the modules and moved to their corresponding trait, the git history only records deletions in the main file Symfony.php, and it will always be possible to use git blame locating you in the repository prior to this commit, this is intended to be part of version 2.0 where changes like these are allowed.

Ok, but is there a quick way to review where each method is located?

Of course, here is the class trait diagram:

Wait, this is the only change for version 2?

No, but it makes the work of the other features much easier, I hope to fix issue #90, add support for codeception 5, remove support for Symfony 3.4 (just like codeception 5 did), and add the functions to assert the orphan events (which were introduced in Symfony 4.1 [they are not documented in symfony far from that PR, but I will document it.]).