Use a stricter configuration for basedpyright

[ItsDrike]

A type checker that isn't strict is a bad type checker

This moves us from the previously used typeCheckingMode, set as standard to using all, with some explicity disabled diagnostics, which we don't want to enforce (blacklist model). This is generally a better idea, as it will also auto-enable any new rules introduced into basedpyright even if they aren't enabled in the mode we're using by default, allowing us to make the conscious decision of whether or not we want to enable it.

Warning

This will likely break all PRs :P

Note that this is the rare case where if you wish to bring your PR up to date with main, you will want to do a proper git merge as opposed to git rebase, so that you can bring your code up-to-date with these changes in that merge commit, rather than having to edit each commit in a rebase to be compatible. Unless you only have very few commits (1-3), or your commits don't change code a lot (documentation PRs).

This is because a rebase would require you to get your code added after these commits will have already been made, which means you will likely encounter git conflicts on every single commit (and even if it won't straight up be git conflicts, your own new code will likely no longer be valid for that commit, as it won't be passing the new stricter type-checker configuration), forcing you to edit that commit. With a lot of commits, you will end up having to edit pretty much all of them one by one, while with a proper merge, you can simply fix the type issues in a single merge commit.

[ItsDrike]

Note: Unknown type reporting is currently disabled, there is a comment in pyproject.toml where these are disabled mentioning that we should consider enabling them. This will however not be done in this PR, instead, it will be covered by a future PR (#333), as I'm not entirely certain if enabling these is a good idea for us, they introduce a LOT of work, and while they can definitely be beneficial, I'm not sure it's worth the annoyance that they bring. I don't really wish to discuss the pros/cons of this in this PR, that discussion should take place in the PR that attempts to enable them.

Note 2: I've added some TODO comments into the code-base, which were not actually resolved here. That's because these TODOs are completely unrelated to this PR and are essentially just issues that I've noticed while working on this. These should be fixed in another PR(s) some time in the future.

[ItsDrike]

Marking this as draft again, pending the consideration of enabling reportUnannotatedClassAttribute. This rule is new and didn't exist at the time this PR was made. I disabled it during the merge with main that bumped pyright, because this rule triggered a LOT of diagnostics, and I haven't yet decided whether it'd be a right choice for us.

[ItsDrike]

Marking as ready again: reportUnannotatedClassAttribute rule will not be enabled for mcproto, it's too annoying without that many benefits.