[Task] Introduce Sphinx-based API documentation and update docstrings

[Apricot-S]

Summary

The project currently does not use Sphinx for API documentation, and many existing docstrings are incomplete or inconsistent.
Some docstrings are already written in reST style, but not uniformly.
This task introduces Sphinx and updates docstrings across the codebase to support high‑quality API documentation for v2.

Scope

• Add Sphinx to the project and set up the initial documentation structure
• Update all public docstrings to follow the chosen style [Task] Update docstrings for the public API #121
• Ensure docstrings are complete, accurate, and suitable for Sphinx autodoc
• Generate API documentation pages using Sphinx
• Add a link to the generated documentation in the README , the Wiki and the pyproject.toml
• Confirm that the documentation builds cleanly and is readable

[Apricot-S]

@Nihisil
I'd like to introduce sphinx before adding docstrings. What do you think?

I need to make sure that sphinx converts the documentation correctly.
For example, the current docstrings don't convert code examples correctly.

The working branch is docs/sphinx.

[Nihisil]

@Apricot-S yep, let's do it

I will stop adding new docs and will wait for the sphinx PR

[Nihisil]

@Apricot-S while doc might have minor issues the main part of this was done. We have doc for major parts of the code with deployed version. What do you think about closing this and 121 ticket? They are last one before 2.0.0 release

[Apricot-S]

@Nihisil
If we close issues 120 and 121, where should we track the problems raised in #121 (comment) ?
Since those comments are related to docstrings, I was thinking it would make sense to continue tracking them in #121.
However, I would like to address the issues mentioned in #121 (comment) before the v2.0.0 release.

As for #245, I think it would be fine to handle it in v2.1.0.