Re #6811. Remove method that breaks encapsulation.

This breaks stuff. Fixing it is the next few steps....
Re #6811. Add a method that returns all running algorithms

...of a given name.
N.B. Had to temporarily comment out some tests that used the removed
algorithms() method.
Re #6811. Use AlgorithmManager's new runningInstancesOf method.

This was the place where there was previously a race condition.
The iterators in the list returned by the algorithms() method
could be invalidated by another thread creating more algorithms.
Re #6811. Re-work & re-enable tests that used algorithms() method.

We can do essentially the same testing via other public methods.
Re #6811. Refactor test to avoid asynchronous algorithm execution.

I found a better way to mimic a long running algorithm rather than
actually having one - just have it always say it's still running
if asked. This is just as good for testing this class as the old way.
Re #6811. Simplify & re-enable previously flaky test.

There's no longer any multi-threaded execution going on, so I think
this test will behave now.
Re #6811. Add a cancelAll() method to AlgorithmManager.
Re #6811. Forward call to AlgorithmManager's cancelAll method.

This is better than pulling out the algorithm list and manipulating
things up the top.
Re #6811. Add method to return newest instance of an algorithm.
Re #6811. Use AlgorithmManager's newestInstanceOf method.

In place of pulling out the list via the (now gone) algorithms()
method and going through it up at this level.
There is a slight difference in behaviour, in that the old way returned
the newest algorithm that HADN'T been executed already. However,
since the dialog is created immediately after the algorithm has been,
I don't see how that can be a problem.
Merge branch 'feature/6811_monitorlivedata_races' into develop