When entity is moved from one collection to another, it is still considered "orphaned"

Hm i think this should be marked as bug

Attached a patch to fix this issue, but its not really final yet.

Architectural questions:

1. Are PersistentCollection::add() and PersistentCollection::remove() the only cases where unscheduleOrphanRemoval() is necessary? What about simple ArrayCollections on a new entity?
2. What about TO_ONE associations with orphan removal?

Patch that solves the issue with ArrayCollections that cannot unschedule orphan removals themselves.

Now only the problem with ONE_TO_ONE relation persists. However this means we might need a new UnitOfWork instance variable. The reason for this is that the Orphan removal of ONE_TO_ONE is detected in "UnitOfWork::computeChangeSets". We cannot use the current "UnitOfWork::unscheduleOrphanRemoval" for this, since it would fail on the following ordering problem:

1. Entity B unschedule Orphan Removal
2. Entity A schedule Orphan Removal again (#fail)

We discussed this issue and came to the conclusion that this behavior is not a bug rather a documentation issue.

Enabling orphanRemoval=true is the semantical equivalent of saying that the orphan entity is privately owned by the parent. That means it should not be re-used!

If you want to re-use entities you should rather look into explicit $em->remove() calls or using cascade=remove.

I updated the documentation accordingly.