[NAD] Add a centralized way to manage stopping conditions in different class of the diagram-util layout algorithms

[NathanDissoubray]

Describe the current behavior

The stopping condition is made directly in the code for each layout class, which includes stopping number of steps sometimes, or custom checks related to the algorithm.

Describe the expected behavior

A centralized way to define stopping conditions for different algorithms. This will also include stopping conditions independent of the algorithm itself, such as a timeout condition.

Describe the motivation

This will allow a standardized interface for a part of the code that every layout algorithm needs. This will also (and mainly), allow us to easily manage timeout for all algorithms (and not require us to implement the timeout checking for each algorithm).

Extra Information

We could make an interface stoppingCriteria (name up to debate) or an abstract class that would provide common methods regarding the timeout and abstract method for the algorithm specific stopping criteria.

We could then make a class for each algorithm. We could also give those class objects to the setup and the post-processing to manage the timeout across the entire process (and not just the algorithm part in the middle).

We could also use this occasion to remove timeout parameters from the AlgorithmParameters of each algorithm since it would be managed in another object. We could also remove conflicting code introduced in #721 where two step limits or two different timeout can be used since there are two entry points to set it.

[NathanDissoubray]

This could be used for the a more precise stopping condition on the Atlas2 Barnes-Hut method.
The calculations are much faster, but it is slightly less precise. At the end of the simulation, adding a few iteration steps doesn't add much calculation time, but usually enhances the visual quality in a noticeable way.

The "hack" that had been found was to increase the number of iterations once we reached the stopping criteria by $\theta$/8 %, but the stopping step increase was removed as it was not very clean.

A better way to do that would be to modify the parameters of the stopping criteria of Atlas2 depending on the value of Barnes-Hut $\theta$.

[NathanDissoubray]

We could also have a stopping criteria based on time instead of an arbitrary stopping condition, i.e.: "run for 10 seconds and give me the result". This would look like a timeout, but here we guarantee that we run the given time (and we don't arbitrarily stop earlier given a criteria).

[NathanDissoubray]

I'm thinking of the following structure:

• timeout is given in seconds at the Layout.run (should not be algorithm dependant so I wouldn't put it with StoppingCondition)
• an interface StoppingCondition with a isStoppingConditionTrue(LayoutContext)
• implementations of the StoppingCondition
• the algorithms can now take a StoppingCondition given by the user, or a default one specific for each algorithm

Edit:
isStoppingConditionTrue(LayoutContext) would not work for Atlas2 for example, as it needs the global graph speed. It can calculate it with only the layout context, but it is calculated along the forces. Having to calculate it again in the stopping condition would basically double the execution time of Atlas2