Transforms haddock3 into a python package

[joaomcteixeira]

Transforms haddock3 into a python package. No changes in code were made yet, those are for future pull requests. So far:

• already incorporates changes from data_path not being found #24 and Update installation instructions #25 (but it is better to merge those PRs first, nonetheless)
• moved haddock folder inside src, this is the end of relative imports. 😺
  • if you wonder why src, please read here, in short, avoids issues with relative/absolute imports, and imports on non-installed libraries. I have been working with this setup for a couple of years now, only with positive results.
• added basic setup.py
• moved haddock3.py to src/haddock/clis/cli.py. After installation users now have the haddock3 command installed in the system.
• updates installation instructions
  • I did not add the requirements to the setup.py file because there was something broken with numpy and lightdock, so I decided not to address that issue in this PR.
• added README.rst for parsing purposes. Now it is empty. In the future README.md will be converted to README.rst.

[rvhonorato]

Great changes, but what do we gain with it? Is the plan to distribute haddock3 via the python package index?

[joaomcteixeira]

Why not? Surely not yet, but why not in the future? Anyway, even if we don't want to distribute it in PyPI we gain a lot having haddock3 structure as an authentic package. Some points I consider positive:

1. end the use of relative imports, which avoids bugs and allows you to import HADDOCK3 machinery anywhere you need.
2. Avoids the use of the global variable script. Instead, the haddock3 executable gets implemented into the system, and we don't need to activate it every time we open a new session.
3. you can have the main function of the haddock3 executable better controlled so that you can use it in other pipelines if needed (I am preparing that pull request).
4. more control in the future when testing with pytest
5. simplified installation instructions, especially if we remove more complicated dependencies (Change LightDock to an optional dependency #29), we can avoid the requirements.txt.
6. adheres to good practices and aligns with what developers and more advanced users expect
7. other positive points aspects will emerge as we continue developing.