ci: Remove toxgen check

[sentrivana]

Description

Removing the Check CI Config step altogether as well as associated parts of the toxgen script (fail_on_changes). Added a BIG ALL CAPS WARNING to tox.ini instead. Also updated the toxgen readme a bit.

Removing the check should be fine because we haven't actually seen cases of people trying to edit tox.ini directly -- if this happens in the future it's easy to notice in the PR. If we don't notice it then, we can notice it during the weekly toxgen update. And if don't notice it then, the file simply gets overwritten. 🤷🏻‍♀️

The Problem With Checking tox.ini: The Long Read

In order to check manual changes to tox.ini on a PR, we hash the committed file, then run toxgen, hash the result, and compare. If the hashes differ, we fail the check. This works fine as long as there have been no new releases between the two points in time when tox.ini was last committed and when we ran the check.

This is usually not the case. There are new releases all the time. When we then rerun toxgen, the resulting tox.ini is different from the committed one because it contains the new releases. So the hashes are different without any manual changes to the file.

One solution to this is always saving the timestamp of the last time tox.ini was generated, and then when rerunning toxgen for the purposes of the check, ignoring all new releases past the timestamp. This means any changes we detect were actually made by the user.

However, the explicit timestamp is prone to merge conflicts. Anytime master has had a toxgen update, and a PR is made that also ran toxgen, the PR will have a merge conflict on the timestamp field that needs to be sorted out manually. This is annoying and unnecessary.

(An attempt was made to use an implicit timestamp instead in the form of the commit timestamp, but this doesn't work since we squash commits on master, so the timestamp of the last commit that touched tox.ini is actually much later than the change was made. There are also other problems, like someone running toxgen but committing the change much later, etc.)

Solutions considered

• using a custom merge driver to resolve the timestamp conflict automatically (doesn't work on GH PRs)
• running toxgen in CI on each PR and committing the change (would work but we're essentially already doing this with the cron job every week)
• not checking in tox.ini at all, but running toxgen on each PR (introduces new package releases unrelated to the PR, no test setup committed -- contributors and package index maintainers also need to run our tests)
• finding a different commit to use as the implicit timestamp (doesn't work because we squash commits on master)
• ...

In the end I decided to just get rid of the check. If people modifying tox.ini manually becomes a problem, we can deal with it then. I've added a big warning to tox.ini to discourage this.

Issues

Closes #4886

Reminders

• Please add tests to validate your changes, and lint your code using tox -e linters.
• Add GH Issue ID & Linear ID (if applicable)
• PR title should use conventional commit style (feat:, fix:, ref:, meta:)
• For external contributors: CONTRIBUTING.md, Sentry SDK development docs, Discord community