Deprecate custom ObjectRepository implementations

[derrabus]

Alternative approach to #9531.

Although the documentation never mentions it, it is currently possible to use an implementation of ObjectRepository as repository class that does not extend EntityRepository. A caller of EntityManager::getRepository() will probably not expect not getting an EntityRepository as return value.

This is why I'd like to deprecate that possibility. This will also allow us to safely use EntityRepository as a native return type in 3.0.

[kbond]

I'd like to voice an objection to this. In my apps, I have my entity repositories implement \Countable. This is not possible when extending EntityRepository because of it's count() method. Edit: I was wrong about this - I can override as count(array $criteria = []).

Still, I have a few concerns:

1. I'd like to keep the extra EntityRepository public methods out of my public API (ie createQueryBuilder).
2. I can have my custom ObjectRepository's implement ServiceEntityRepositoryInterface in a way that keeps the constructor clean for injecting additional services (using setter injection with the Required attribute).

Admittedly, these are both minor - my main concern was being able to implement \Countable.

[derrabus]

Indeed, Countable can be implemented by repositories, so that should not hold you back.

Regarding the other concerns:

• I don't see a big problem with a repository having a createQueryBuilder() method. In fact, somone experienced with the ORM who joins your project might be surprised if your repositories don't have that method.
• That might be a matter of taste, but imho there's nothing clean about injecting a mandatory dependency in a setter. Symfony's service entity repositories can alaredy have any dependencies you want.

Looking at the alternatives (#9531 mainly), this PR still seems to be the best option to me.

[kbond]

For a bit of context, I've been working on a library (very wip) that provides an opinionated entity repository (iterable, countable, read-only vs writeable implementations). It's optimized for large data sets.

I don't see a big problem with a repository having a createQueryBuilder() method.

Excluding was an attempt to lock user's out of "doing whatever they want" outside of the repo itself.

...there's nothing clean about injecting a mandatory dependency in a setter.

Clean was a poor word choice on my part. My library's "repository" classes are abstract and force you implement ObjectRepository::getClassName() and a protected em(): EntityManagerInterface method. How you do so is up to you but I provide an optional DX helper (that uses the setter injection) to make it easier to use with Symfony.

This change throws a bit of a wrench in my vision but isn't something I can't work around.