feat: automatically call adders for Doctrine collections

[nikophil]

(trying to) fix #1100

[mpiot]

@nikophil I use this PR + feat: not persist reverse relation when withoutPersisting() mentioned (#1116) for testing

While testing, it look likes the PR do:

• on an entity with a setter, call the adder of the relation, not the entity setter

In my mind, if the Entity:

• use a setter, call the setter,
• use an adder, call the adder
• public, just set if no setter/adder

But not:

• the entity have a setter, but the related entity define by the setter have an adder, then I call that adder.

[nikophil]

@mpiot not sure to understand fully what you mean, but if an adder is present, I think it should be used in priority, because adder might add extra needed logic (like set the other side of the relation).

This is, by the way, the default behavior of the property accessor (adder > setter > public prop), this seems to be kinda of a convention, so I don't think I will change this, unless this cause bugs

[mpiot]

@nikophil I’ll double check tomorrow but while testing it looks like in a similar case:

 A
   bs: Collection<B>
   addB(B)
  
B
   a: A
   setA(A)

If I use the B factory, it doesn’t do B->setA(), but: A->addB(). Strange behavior because I use the B factory, I’ll expect it use the setter, not the adder of the related entity. If I’m using the A factory, and define B classes, I’ll expect it use the adder: A->addB().

[nikophil]

If I use the B factory, it doesn’t do B->setA(), but: A->addB(). Strange behavior because I use the B factory, I’ll expect it use the setter, not the adder of the related entity. If I’m using the A factory, and define B classes, I’ll expect it use the adder: A->addB().

this makes sense indeed, maybe harder to do it than it seems, I don't know, don't hesitate to edit the code of this PR in another one