Improvements to make.py and pyright configuration

[cspotcode]

I would have submitted as 2x PRs, but unfortunately one depends on the other and stacked PRs don't really work if you're submitting from a fork.

These changes are extracted from #1738 plus some things we talked about on Discord. Hopefully this changeset is purely non-controversial stuff.

• adds ./make.py pyright but does not add it to ./make.py lint
• improve pyright config, telling it how to typecheck deps that don't bundle types
• add categorization to typer subcommands
• tweak contributing.md since make.py gets execute bit automatically, no need to chmod manually

[pushfoo]

tl;dr this looks good overall, especially splitting the sections further, but it raises some new questions

In addition to the specific comments I made on the files, I have some questions before we merge. Please keep in mind:

• Not all of them need to be addressed in this PR
• Since I made the suggestions, I can pick up the slack on implementing some of them if you're busy

Questions:

1. Can we group the shell completion commands into a new "Shell Completion" group?
2. Can we rearrange the order of the command groups?
3. Can we hide or further control the extra format grouping?
4. Can we move linkcheck into Coding / Code Quality?

It think it's worth cleaning up the output further to be focused on what people use most frequently. Some of the extra formats are definitely worth keeping (epub, PDF, single html, man, .txt), but not immediately relevant to most users.

[cspotcode]

Review feedback addressed.

It think it's worth cleaning up the output further to be focused on what people use most frequently.

Funny enough, for long output like this, if we put them at the top then they're likely to scroll off the top of the screen, leaving only the less important ones visible.

I'd like to merge this PR as-is, and follow-ups can re-order the output.

[pushfoo]

I think this is good, and I agree with the point about the current arrangement of the long output.

Shortening and rearranging the output requires further thought, so we can probably merge this as-is for now.