Merge networkx from python-type-stubs

[Avasam]

This PR merges the stubs from https://github.com/microsoft/python-type-stubs/tree/main/stubs/networkx so that removing them from there produce no regression for Pylance users.

I didn't make much effort in completing annotations other than validating what I was copying over.
In doing that I did find quite a handful of incorrect annotations though.

I've already started a few PRs, and will create more that have specific scopes to make it easier to review these changes in chunks. (and will serve as self-review for this big PR). Until then, I'll keep this as draft.

[yangdanny97]

Hi! I'm currently experimenting with a semi-automated way of extracting types from docstrings and applying them to stubs. Networkx was on my radar since the docstrings are very detailed and there is definitely some missing coverage.

I wanted to check in and see what I should do to avoid causing merge conflicts for you. Should I hold off till all of these changes are merged? Are there directories that you're done with that I can start looking at?

[Avasam]

Hey @yangdanny97 !
These stubs are nothing more than https://github.com/microsoft/python-type-stubs/tree/ee6d039e893b5401e4b85c6229bafed3b984a941/stubs/networkx
I don't trust their validity at all though (and rightfully so from what I've seen so far, part because some of it's obsolete, part because of what I'll describe below). So I've been extracting changes in chunks form this PR, and validating those.

These stubs were initially created using https://github.com/gramster/docs2stubs (which you may want to look into for docstring to stubs generation, I think stubgen is starting to have some support as well). Meaning networkx' own docstrings can be quite incorrect at times. Sometimes it's because they're taking shortcuts or using terms they're more familiar with despite being technically incorrect (labeling something a variable-length tuple when it could be any Iterable, labeling an Iterable a list, etc). Sometimes it's using a term that doesn't exist in the type system (for example Array, which may or may not be a sympy matrix or a numpy array). And sometimes it's just flat out wrong.
Oh also sometimes the annotated type can differ from the docstring because it is transformed by a decorator.
So you may end up with a lot of work/changes to do upstream to get accurate stubs generated from docstrings.

That being said, I'm working on this at a leisurely pace (and have other priorities atm with a big event in September). If we end up with conflicts that would simply mean I'd have to double-check the actual implementation. I wouldn't worry too much about that.

[github-actions]

According to mypy_primer, this change has no effect on the checked open source code. 🤖🎉