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)
• 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)
• 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

• 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 mdolab/sphinx_mdolab_theme#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.