Add workflow algorithm for POLDI analysis

[MichaelWedel]

This fixes #10702.

Please note that I started on the ticket earlier in a different branch, which was abandoned. Only the commits in this pull request are relevant. For the next release I will create a workflow chart and include it in the documentation.

Testing information
Make sure all tests pass, I fixed a few bugs in some of the POLDI algorithms along the way and had to fine-tune PoldiFitPeaks2D to handle multiple phases.

There is a documentation page for PoldiDataAnalysis including a usage example. Make sure it works, you could also look at the plot that is generated when the option is activated and see that the green curve (difference curve) is not too high compared to the red/black curve. If the PawleyFit option is deactivated, the fit should be faster, but the unit cell information is not generated.

[AndreiSavici]

You should fix your pylint warnings:

• for unused variables (say a=Load(filename), then unused a) just use dummy_variable_name instead
• add newlines at the end of the files
• add a statement to ignore variables defined outside init. Most python algorithms have this

[MichaelWedel]

Thanks Andrei, I missed the pylint warnings. But why was the indicator green?

[AndreiSavici]

For now the threshold is set to 4000 warnings. We need to fix a few more, to slowly get it down

[FedeMPouzols]

All looks good, and extensively documented and tested. I run the system and unit tests locally just in case, without surprises.

Maybe one small thing that could be added to the tests later on is some test cases with wrong properties (users mistype or forget a required property, etc.). And I am not sure if it is possible to have wrong combinations of properties (and/or property values), that could also be added in the unit tests.

I also have a general comment about unit tests, actually forwarding a comment from Owen some days ago on one of my PRs. The idea is to prefer the TSM_... versions of the CxxTest asserts rather than the TS_... adding informative messages wherever it makes sense, so that we can quickly get an idea of what's the issue when a unit test fails. Hum, but I see now that TSM is already used in many places already in these tests ;)

[MichaelWedel]

Thanks for testing thoroughly! You're right, I do not use TSM_ too often, I will pay more attention to this in the future. So far I tried to use them in "bulk" tests where the same check is run for similar data in the same test. Another thing I'm trying to work on is to make smaller, more specific test-cases, which makes it also easier to spot where an error originated, just from the name of the test-case.