[checks] Implement Python checks and fix some violations

[eisenwave]

Fixes #8086

I've mentioned the option to improve the checks in Croydon to @tkoeppe, and he seemed generally open to the idea.

In summary, this PR converts all the checks we have in check-source.sh (plus some additional once adopted from check-output.sh) and turns them into a Python script. The benefits are:

• Much nicer formatting for errors. You get VSCode-friendly source locations that you can use to navigate directly to the line and column in an editor. You also get a citation of the source with the affected column span highlighted, so you're not left guessing where the error is located.
• No more hieroglyphic sed and grep piping. The code is relatively simple Python. It still uses a bunch of regular expressions for a lot of checks; the greatest benefits are in the more complex checks.
• Ability to write test cases for checks using EXPECTCHECKNEXTLINE.
• Ability to enable and disable individual checks for source spans using NOCHECKBEGIN and other directives. This makes it possible for us to add much more aggressive checks that would have previously been infeasible because they generate too much noise in old TeX sources.
  • A good example of that is in this PR, where I disable the check for \tcode{\exposid{...}} in a part of numerics.tex because there are too many violations.
  • We could also use this to e.g. disallow use of \textit in "newer" TeX ranges for example without having to fix every single violation. We could also use it to catch many "bad words" or "bad phrases" that appear too often to be checked right now, but that we don't want perpetuated.
  • We could also use this to enforce a little bit of auto-enforcement of semantic line breaks (such as requiring a new line after a sentence period) without needing to fix the countless existing violations.
• With check suppression, it is possible to suppress checks that would have inevitably failed during motions. For example, if there is a dangling \ref to a section that is introduced by another paper, you can still get a green build by suppressing the \ref check (that is, at least for the check-source checks).

There are a few notable new checks that make things a lot easier in the future:

1. base-env-balancing checks for balancing of \begin and \end commands. It's quite easy to get it wrong, and when you do, it tends to blow up after minutes during the TeX build in bizarre and hard-to-debug ways.
2. base-unknown-command checks for use of TeX commands that have never appeared before in the code base. It's very unlikely that this is intentional in most PRs, and very likely that someone just wrote \tocde instead of \tcode or something else stupid. If we need a new TeX command, we can just add it to the list.

[eisenwave]

Some more neat examples:

[eisenwave]

Latest innovation:

[Tsche]

I'm not sure pyright is a good call. There are other alternatives that do not require pulling in node as dependency.

[eisenwave]

I just use it because it integrates nicely with VSCode out of the box. What would you recommend instead?

[Tsche]

emit_check_failure is only called from within classes deriving from Check. Can you fold it into fail and consistently use this one?

[eisenwave]

After the changes in 7af3d56, I wouldn't want to. The difference is that fail is just a convenience function that provides the file path automatically, and I would want there to be a global "emit failure" function at some level, in case we expand the sources of failures in the future.

emit_check_failure is basically the global console.error counterpart, and that has kind of a right to exist even if you always use it via a wrapper. That might change at some point.

[eisenwave]

@Tsche thanks a lot for the review. It'll take some time to clean it all up.

[eisenwave]

All the pre-existing issues are taken care of in separate PRs. Now comes rebasing on the latest motions and addressing all the feedback on the Python script.