Add stubs for XDSM

[Aidavdw]

Purpose

Fixes #58 by adding .pyi files for XDSM

Expected time until merged

Should be relatively trivial, as it's a single file. Not really that urgent.

Type of change

• [ ] Bugfix (non-breaking change which fixes an issue)
• [X] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (non-backwards-compatible fix or feature)
• [ ] Code style update (formatting, renaming)
• [ ] Refactoring (no functional changes, no API changes)
• [X] Documentation update
• [ ] Maintenance update
• [ ] Other (please describe)

Technically a feature? Technically documentation? Whatever, type checking!

Testing

Check if pyright and MyPy correctly load and interpret the .pyi file. I have already tested this on my local machine.

Checklist

• [X] I have run flake8 and black to make sure the Python code adheres to PEP-8 and is consistently formatted
• [ ] I have formatted the Fortran code with fprettify or C/C++ code with clang-format as applicable
• [ ] I have run unit and regression tests which pass locally with my changes
• [ ] I have added new tests that prove my fix is effective or that my feature works
• [ ] I have added necessary documentation

[A-CGray]

Thanks @Aidavdw , docs build failure should be fixed by https://github.com/mdolab/sphinx_mdolab_theme/pull/17

Could you provide some sort of MWE that demonstrates your stubs working that I can run myself?

[Aidavdw]

As this is more of an editor-specific thing, I'm not quite sure what constitutes an MWE. Could you elaborate? Do you want me to give you a small configuration & setup for an editor that uses e.g. pyright to show that it shows up correctly, or do you want a small file using the library where using the stubs correctly resolves the issues pyright brings up without them?

[A-CGray]

Yeah I just mean could you provide a small pyXDSM example that uses type annotations that I can test in my own editor

[ewu63]

Is there a particular reason for using stub files instead of inline type annotations? IMO annotations are much more flexible/readable/maintainable, so unless there is a strong preference I am leaning towards rejecting this PR. I understand that the package to date does not really offer any types, but that's something we can add incrementally, and looks like it's being added as part of #61. In any case, we anticipate substantial code changes so I don't think this PR is worth it anymore.