Introduce proxy class name resolvers

[alcaeus]

The metadata factory tries to resolve a proxy class name to get the real class from it. However, this only works when using proxies from doctrine/common. MongoDB ODM 2 and ORM 3 will use ProxyManager to create proxy objects, which requires workarounds in ODM whenever metadata is fetched.

This PR introduces a small interface that can be used to implement and inject such class name resolvers. If no resolver is defined, it falls back to using the current logic. Note that the resolver is implemented in this package as doctrine/common is a dev dependency and thus not available when doctrine/persistence is used in userland code.

[greg0ire]

I pushed a fix for static analysis, let's trigger a build on a different merge commit.

[malarzm]

I remember needing a real class name in quite few projects I was working on in the past, I think it'd be helpful to have a real DoctrineProxyClassNameResolver one can depend on instead of an anonymous class

[alcaeus]

Note that this is very much internal, as ocramius/proxy-manager already provides a public interface to fetch the real class name from a proxy object. This is only glue code to be able to inject those resolvers into persistence to ensure metadata fetches are done on the real class.

Since ORM still uses common proxies (with Doctrine\Common\ClassUtils to provide the real implementation name), I believe it makes sense to not expose a fully fledged class here.

[beberlei]

You are reimplementing the common function ClassUtils::getRealClass here, i am wondering if we should just hardcore proxy manager support in there too. This would be much better than deprecating this code, there is so much depedent code out there using these APIs.

[beberlei]

See doctrine/common#867 and the referenced code from a user DamienHarper/auditor-bundle#143 doing just that.

[alcaeus]

You are reimplementing the common function ClassUtils::getRealClass here, i am wondering if we should just hardcore proxy manager support in there too.

Not going to happen. I duplicated our own logic to avoid a dependency on doctrine/common, but I can refactor this to try and use ClassUtils::getRealClass if it exists and do nothing if no resolver was set. Duplicating internal logic from a third-party package when that package provides a public API to do this work is not feasible here.

Note that we won't be able to get around doing this kind of logic here either: since Doctrine offers to return proxy objects when fetching from the database, it should be very much capable with receiving proxy objects or their class names in its logic. Each implementation of the Doctrine persistence API (e.g. ORM or ODM) can inject their resolvers depending on the solution they use for proxies.