Add Python type stubs

[hallofstairs]

What changes were proposed in this pull request?

This PR introduces an automated process (gen-stubs.py) for generating Python type stubs (__init__.pyi, algorithms/__init__.pyi, graph_gen/__init__.pyi, graph_loader/__init__.pyi, graphql/__init__.pyi, vectors/__init__.pyi) for Raphtory. These stubs provide type information for the Python interface of Raphtory, enhancing type checking and IDE support.

Also, a make stubs command was added to the Makefile to streamline the stub generation process, and a mypy test was implemented to verify the general correctness of the generated stubs.

Why are the changes needed?

The addition of auto-generated Python type stubs will:

• Improve the developer experience for users of Raphtory by enabling better autocompletion and type checking in IDEs.
• Reduce the likelihood of type-related errors by allowing static type checkers (like mypy) to catch issues before runtime.
• Serve as a form of documentation, making it easier for users to understand the expected types for function parameters and return values.
• Ensure that Python type information stays up-to-date with the Rust codebase by automating the generation process.

Does this PR introduce any user-facing change? If yes is this documented?

This PR does not introduce any functional changes to the library, but it does improve the user experience for developers using type-aware tools. This change is self-documenting, as the type stubs themselves serve as documentation.

How was this patch tested?

• The auto-generation script was tested to ensure it correctly extracts type information from the codebase.
• Running a static type checker (mypy) against the stubs to ensure they are valid.
• Manual testing in various IDEs (PyCharm, VSCode) to verify improved autocompletion and type inference.
• Verifying that existing Python code using Raphtory still works without modifications.

Are there any further changes required?

• Integration of the stub generation process into the build pipeline to ensure stubs are always up-to-date.
• Potential future improvements could include:
  • CI/CD to automatically regenerate stubs when docstrings or function signatures change.
  • Refinement of the generation script to handle more complex type scenarios.
  • Addition of further tests to verify the correctness of generated stubs against the actual implementation.