Fixes some long-standing issues that have to do with commit order computation and cyclic associations.

When performing inserts or deletes of entities, the ORM tries to find a sequence of operations so that all foreign key constraints can be satisfied. Basically, before inserting an entity, all other entities it refers to have to be inserted. And before deleting an entity, all other entities that refer to it have to be deleted, or database-level SET NULL has to be used.

The current implementation for this works at the entity class level. It checks which entity class refers to which other class(es), and based on this information, computes an ordering of entity classes. Then, all entities of the first class will be processed, then those of the second class and so on. The same ordering is used for deletions.

In the PRs #10531 and #10532, two examples are given why this is not sufficient: There may be references between entities of the same class, so that we can only insert those in the database by looking at their associations at the entity level. Or, we may have references between entities of two different classes that require us to go back and forth – insert one entity of the first class, before we can insert one for the second class, before we can go back to the first class for a third entity.

Then, there is a shortcoming in the current CommitOrderCalculator: It does not detect cycles at all. This refers to situations where we cannot find a commit order because every single entity to be processed requires another one to come first. Cycles can be broken at NULLable foreign keys, where a NULL value can temporarily be used and the value updated at a later stage. This is called "extra updates". Places where such extra updates can be used to save the day can be found by backtracking in the commit order computation, in case cycles are found.

Last, the commit order for INSERTs and DELETEs needs to be based on different criteria: INSERTs can make use of extra updates and require NULLable foreign key definitions for this to work. DELETEs, however, currently do not make use of such extra updates. For them, whether the database can use "SET NULL" on foreign key deletions is the important factor.

To make it possible to review the changes, they were broken down into a series of independent PRs against a temporary branch. This PR here does a final merge of the result into 2.16.x.

The individual PRs are:

• Add a new topological sort implementation #10592
• Prepare entity-level commit order computation in the UnitOfWork #10651
• Compute entity-level commit order for entity insertions #10689
• Commit order for removals has to consider SET NULL, not nullable #10566
• Add a test case to show #10348 has been fixed #10732
• Add tests to show #6499 has been fixed #10749
• Add test to show #7006 has been fixed #10750
• Add test: Commit order calculation must happen on the entity level #10531
• Add test: Entity insertions must not happen table-wise #10532
• Add test to show #7180 has been fixed #10751
• Add test to show #9192 has been fixed #10755

(Potentially) fixed issues/closed PRs:

• fixes Commit order issue #5538, although no complete test was provided
• fixes Persisting entities with OneToOne and OneToMany/ManyToOne relationship between them. #6499, tests were picked from commit order must consider non-nullability of join columns as prioritised over nullable join columns: Take 2 #7180
• closes #6499 commit order must consider non-nullability of join columns as prioritised over nullable join columns #6533, tests were picked from commit order must consider non-nullability of join columns as prioritised over nullable join columns: Take 2 #7180
• closes Change persistence ordering for OneToOne to allow making JoinColumns non-nullable #8703, it was using the tests from Persisting entities with OneToOne and OneToMany/ManyToOne relationship between them. #6499 as well
• fixes Incorrect commit order when inserting multiple entities #7866, using the same tests as Change persistence ordering for OneToOne to allow making JoinColumns non-nullable #8703
• fixes Wrong commit order in some relation cases #7006, tests added via Add test to show #7006 has been fixed #10750
• closes commit order must consider non-nullability of join columns as prioritised over nullable join columns: Take 2 #7180, picked tests from their PR and extra tests from discussion comments via Add test to show #7180 has been fixed #10751
• fixes [2.10.2] Ignore dependencies having onDelete="SET NULL" when computing commit order for removal operations #9192, added a test via Add test to show #9192 has been fixed #10755
• closes Order of referenced child deletions not correct when referencing to itself #10348, adding tests via Add a test case to show #10348 has been fixed #10732
• closes Fix commit order #8349, their tests being included in Add a new topological sort implementation #10592

Not fixed issues/PRs:

• DDC-601: UnitOfWork commit order problem #5109 – this is about extra unique constraints and/or performing DELETE before INSERT, beyond what the ORM requires itself to make foreign keys work; similar in Flush could delete entities before inserting new ones #5742, oneToMany orphanRemoval with unique - constraint violation #6776
• Cascade deletion complicate-referenced entities does not work [ForeignKeyConstraintViolationException] #5665, Failing test: UoW unable to break cycles when removing entities without DB-level cascade #10548 – those are about scheduling extra updates before DELETE, to null out foreign keys and not require a database-level SET NULL

(Probably) related issues/PR with unclear state and/or missing reproducers:

• Doctrine tries to delete entities in incorrect order #9376
• Compute particular commit order for deletions #9377

Definitely too big for this PR:

• Performance: Persisters no longer being able to batch inserts
• Performance: Optimizing the DFS to find a minimal feedback arc set/minimize the number of scheduled extra updates