Makes lychee accept status 429 (too many requests) as a successful check. This makes some sense: a 429 may very well be a live link, just one that currently you are not allowed to view. If it were a broken link, the server should return 404 instead. I'm not 100% sure if all webservers work this way (i.e. if they first check for 404 and only then apply throttling to give 429), but in any case it seems the best we can do, because we cannot otherwise control request rate from GitHub Actions, as far as I know.
Adds a manual run trigger to the link checker
Removes the workflow part where we only fail if there are 10 or more broken links. I think we can get to 0 broken links by using lychee options, like indeed the one above for 429 and handling other broken links properly as well or excluding them explicitly. I think this is preferable to leaving up to 9 broken links for possibly a long time.
This PR: