[FEATURE]: Add typechecking for codebase

[vhyrro]

closes #1160

This PR adds a github workflow which verifies the types of all Neorg's code. I expect it to complain quite a lot so the next step will be to clean up all of the type errors it throws :p

Thanks to @pysan3 for the idea!

[vhyrro]

And indeed it throws a lot of errors. The next logical step will be to go in and clean it all up one by one in another PR! If anyone's happy to also help out with this then feel free to make your own pull requests :)

[pysan3]

Hey @vhyrro , looks like a good step forward.

I am definitely willing to help out but this will require somewhat big rewrite of many code, which will definitely make tons of conflicts between other PRs and other ongoing works.

Should I start off with modules that have smaller impact (do you have any suggestion?) and make PR bit by bit (maybe module by module?), or should I make a giant PR and experience the resolving conflict pain only once?

[pysan3]

@vhyrro people might be afraid of the ❌, so shall we add ---@diagnostic disable-line for all places where the test is failing as a temporary solution?

If yes I'll make a PR tomorrow at the earliest.

[vhyrro]

Hey @vhyrro , looks like a good step forward.

I am definitely willing to help out but this will require somewhat big rewrite of many code, which will definitely make tons of conflicts between other PRs and other ongoing works.

Should I start off with modules that have smaller impact (do you have any suggestion?) and make PR bit by bit (maybe module by module?), or should I make a giant PR and experience the resolving conflict pain only once?

Most of the changes should be minor things like checking types (type(var) == "XYZ"), adding type annotations or adding nil checks. I don't expect those to cause large merge conflicts so I'd rather many small PRs with a few fixes each :)

[vhyrro]

@vhyrro people might be afraid of the ❌, so shall we add ---@diagnostic disable-line for all places where the test is failing as a temporary solution?

If yes I'll make a PR tomorrow at the earliest.

We could do that yeah. Perhaps parse the json that the github action generates and just write a script that adds that line everywhere, then go through each annotation bit by bit.

[Anrock]

From my experience of introducing style / type / lint / diagnostic checks to whole (non-confirming) database the best way was to add the checker with corresponding check steps in pipeline and simultaneously put every checkable code file into global ignore file (effectively making the check noop) in the first PR and then fix and take out modules/files one by one from ignore file in multiple separate subsequent PRs. This way has almost no friction for finishing and merging existing PRs. If some friction is okay: the first step shouldn't put files into ignore list if they're green initially.