Refactor rigidbody module to allow the preparation of cns_input to be done in parallel

[rvhonorato]

You are about to submit a new Pull Request. Before continuing make sure you read the contributing guidelines and that you comply with the following criteria:

• You have sticked to Python. Please talk to us before adding other programming languages to HADDOCK3
• Your PR is about CNS
• Your code is well documented: proper docstrings and explanatory comments for those tricky parts
• You structured the code into small functions as much as possible. You can use classes if there is a (state) purpose
• Your code follows our coding style
• You wrote tests for the new code
• tox tests pass. Run tox command inside the repository folder
• -test.cfg examples execute without errors. Inside examples/ run python run_tests.py -b
• PR does not add any dependencies, unless permission granted by the HADDOCK team
• PR does not break licensing
• Your PR is about writing documentation for already existing code 🔥
• Your PR is about writing tests for already existing code

---

This PR refactors the rigidbody module to crate the prepare_cns_input in parallel.

To make it """ simpler """ I've added a GenericTask to libparallel that wraps a function call into a class that can be paralelized with the current Worker/Scheduler.

Since I also added some integration tests, I also had to add some golden data - hence the huge number of changes, you can ignore those files. I also added new tests for the new class methods.

[VGPReys]

Because you know that the parallel approach is better for high number of len(models_to_dock) * sampling_factor.
Maybe checking that len(models_to_dock) * sampling_factor < 3000 or self.params["mode] == "batch" to trigger the prepare_cns_input_sequential else prepare_cns_input_parallel ?

[rvhonorato]

yep we can do that, but needs to come up with a magic number. Since the speedup threshold will depend on the number of cores and processor architecthure - I'd leave as it.