Rewrite for py-tree-sitter 0.22

[ObserverOfTime]

This PR rewrites the project to make it work with py-tree-sitter 0.22.

• The user-facing API is still the same.
• Each language is compiled into a separate module.
• Adding new languages is much easier than before (see CONTRIBUTING.md).
• Languages that can currently be installed from pypi (or built from git) are removed.
• Wheels for niche architectures are no longer built (just like py-tree-sitter).

Fixes #55, closes #60, fixes #61, fixes #63, fixes #64, fixes #67

---

Don't take this to mean I will be maintaining this project going forward.

If @grantjenks is still unable to maintain it and doesn't want to give it to some random person,
then someone can fork it, pull my changes, rename the package, and maintain the fork.

But don't try to package all ~400 languages. Just some popular ones that don't yet have a package.

[mbhavya]

This PR rewrites the project to make it work with py-tree-sitter 0.22.

* The user-facing API is still the same.

* Each language is compiled into a separate module.

* Adding new languages is much easier than before (see CONTRIBUTING.md).

* Languages that can currently be installed from pypi (or built from git) are removed.

* Wheels for niche architectures are no longer built (just like py-tree-sitter).

Fixes #55, closes #60, fixes #61, fixes #63, fixes #64, fixes #67

Don't take this to mean I will be maintaining this project going forward.

If @grantjenks is still unable to maintain it and doesn't want to give it to some random person, then someone can fork it, pull my changes, rename the package, and maintain the fork.

But don't try to package all ~400 languages. Just some popular ones that don't yet have a package.

Hi @ObserverOfTime great work.

Can you please elaborate how do you decide which languages make the cut and which don't ? As I understand, different developers will have different requirements.

Also, I understand maintaining so many languages would be impractical, but shouldn't then there be a way to help a developer install additional language support at runtime (post installation of package via pip) and not have to go via PR and build process to get that language support ? Maybe it can be achieved via documentation highlighting detailed steps.

[ObserverOfTime]

You can add any grammar you want here (see CONTRIBUTING.md for the process) but I chose not to add those that have been updated upstream and can be installed from pypi or git.

You can also submit a PR to grammars that have not been updated:

1. Run tree-sitter generate to generate the new bindings.
2. Fix inconsistencies in the generated bindings (e.g. versions & scanners).
3. Optionally add CI & packaging workflows (will require the maintainer to set up their tokens).