Improve the compatibility layer for Doctrine DBAL to avoid side-effects of polyfilling

[ste93cry]

This is an attempt at fixing #483 and #484. I decided to split the TracingDriver class into two versions, each compatible with just one of the major versions of Doctrine DBAL we support (2.x and 3.x)

[ste93cry]

After thinking again about this, and while we have some clear advantages of splitting the implementation into two, e.g. the fact that we can add typehints to more things and evolve the two classes independently without worrying about keeping the compatibility with both major versions at the same time, I'm pretty sure this does not solve #483 and there is no way to solve it. Basically, the DebugClassLoader of Symfony blindly parse the annotations on the classes that it loads and as soon as it finds one that is marked as deprecated and that is loaded from something outside of its vendor it reports the deprecation. In our case, we need to implement those deprecated interfaces to expose the fact that the decorated driver implements them, since it's quite common to use an instanceof check in this context. I still think that my comment about Symfony not making his own business applies perfectly in this case, the thing that the DebugClassLoader is doing would be better suited for a static analysis tool which has far more understanding of the context around how the code is called and how it works

[Jean85]

LGTM 👍 splitting is surely a better approach.

Maybe we should declare those implementations @internal?

[ste93cry]

Maybe we should declare those implementations @internal?

Yes, that's a good idea!

[starred-gijs]

I got an E_WARNING:

Stack trace
E_WARNING: Cannot declare class Sentry\SentryBundle\Tracing\Doctrine\DBAL\TracingStatement, because the name is already in use
in class_alias called at /app/vendor/sentry/sentry-symfony/src/aliases.php (93)
in require called at /app/vendor/composer/autoload_real.php (71)
in composerRequire4d23fd274a12f9ca19dfa7bc29152b16 called at /app/vendor/composer/autoload_real.php (61)
in ComposerAutoloaderInit4d23fd274a12f9ca19dfa7bc29152b16::getLoader called at /app/vendor/autoload.php (12)
in require called at /app/public/index.php (7)

[starred-gijs]

This PR fixed it already I guess #552

[Jean85]

#552 is released as 4.2.3, you can test it out.