Requiring status checks before merging

Nobody has claimed this yet.

Github allows for restricting merges to certain branches in various ways:
- allowing only admins to merge
- requiring a certain number of approvals before allowing a merge
- requiring status checks to pass before allowing a merge

This is all documented here: https://docs.github.com/en/free-pro-team@latest/github/administering-a-repository/defining-the-mergeability-of-pull-requests

We should institute similar restrictions to prevent accidentally merging PR's with failing tests into incorrect branches, as happened today with #1778.

To make matters worse, after that PR was merged into master, master was merged into release-1.17, then release-1.17 was merged into development and pre-master. This is excessive and confusing, and has lead to **all four active branches** to be in a failing state!

Moreover, now that there's a fix (#1782), even fixing it will leads to a spaghetti of merges between these 4 branches, because we have to do 4 merges to fix all the branches! I think we should also reduce the number of parallel active branches to only master and development. As I explained in https://github.com/Macaulay2/M2/issues/1691#issuecomment-747184042:

> If we use tags instead of branches for each release, including release candidates, then I don't see a reason to keep the `release-*` branches: whenever you have a commit that's reasonably ready, tag it `release-1.17-rc1`, when new issues are found and fixed, tag `release-1.17-rc2`, until it's ready to be tagged `release-1.17`.

Start with the linked GitHub mergeability documentation and the repository's active branch configuration, then review the related issues #1778, #1782, and #1691. Define the required status-check and merge restrictions and decide whether release branches should be replaced by tags. Done means the agreed branch policy is implemented and the active branches no longer permit the described unsafe merges.

Written by the indexing model from the issue text.