feat: Add a typos CI job

[Muscraft]

Over the past few months, I have noticed various PRs that were created to fix typos, and figured that it would be a good idea to add a non-blocking¹ CI job that runs typos² to hopefully catch typos before they are merged into the codebase. The configuration file for typos in this PR is meant to get the ball rolling and is by no means perfect.

Footnotes

1. I chose to make this non-blocking, so any newly added corrections don't cause CI to fail. ↩

2. The workflow file for the job matches the one in annotate-snippets-rs ↩

[rustbot]

r? @ehuss

rustbot has assigned @ehuss.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[epage]

Do we want this to block CI?

If so, we have to do one of

• change settings on the repo
• put this in the main workflow and have Conclusion depend on it

(iiuc)

[epage]

We also should pin the job and have renovatebot update it

[weihanglo]

IMHO it should be a non-blocking job first:

• We don't know how reliable it is (e.g. how many false-positives it has)
• We don't want to block the PR just because some new identifier needs to be added to the typo config

[epage]

Sounds like these are summarized as "we don't know how much of a pain this will be, are we sure we want to commit?".

However, we do have history for this

• rust-lang/rust has adopted this and you can see how much churn their config has
• I've been using this in all of my repos for years with much stricter configs than cargo and rust

On the other hand, by not having it be blocking,

• We might enable auto-merge and miss that typos has failed
• We confuse contributors when with existing failures
• We confuse contributors with whether they are accountable for it (the UI does not make it clear when jobs are non-blocking)