feat: update to tree-sitter 0.24

[ObserverOfTime]

• Add the new tree-sitter.json config file
• Remove existing binding files
• Run tree-sitter init to create them anew
  • Manually tweak a few of them
• Include Cargo.lock in versioning instructions

[ObserverOfTime]

The next tree-sitter CLI release will finally have a command to handle this.

[dundargoc]

Combining automatically generated code with manual tweaks sounds like it could be a problem if something goes wrong and we need to bisect/recreate. Could we separate the automatic and manual changes with different commits/PRs perhaps?

[dundargoc]

Oh, and if possible, think we could use the latest tree-sitter commit (since it shows the exact tree-sitter SHA that was used to generate)? It could become relevant to know the exact TS version if things go wrong.

[ObserverOfTime]

Can I just specify what was manually changed instead?

[justinmk]

That would be a good starting point. I will separate those changes into a separate commit if you can't.

[clason]

If Justin won't, I will require separate atomic commits. These sort of "update repo" PRs are simply unacceptable (even though -- most of -- the changes are welcome).

Oh, and if possible, think we could use the latest tree-sitter commit (since it shows the exact tree-sitter SHA that was used to generate)

I would prefer to stick to releases for generating files; 0.25 will be a breaking change (new ABI version), and I'd like to separate that step for later (even though we'd have to wait a bit for the parser annotation).

[dundargoc]

I would prefer to stick to releases for generating files

Same, but I'm pretty sure this was not generated from a stable version but from a random commit (no idea which one). I figured if we were going with a non-release commit then at least we could pick the one the let us know which one.

[clason]

Same, but I'm pretty sure this was not generated from a stable version but from a random commit (no idea which one)

Then this is another reason to ask for a change. These files should be generated with 0.24.3 (or 0.24.4 if that is imminent, in which case we should park this).

[ObserverOfTime]

Might as well park it till 0.25 then.