Auto-reject PRs that do not meet `CONTRIBUTING.md` guidelines

[qstokkink]

Doing things manually takes time we could spend elsewhere. The guidelines in CONTRIBUTING.md can be partially automated without this time-consuming manual intervention. We should probably reject PRs by giving the PR author an angry automated message that tells them to RTFM (CONTRIBUTING.md). However, in all fairness, any contributor that does not even read the 9 sentences in CONTRIBUTING.md probably deserves to have their PR auto-closed.

We can enforce the following 3 rules when opening a new PR:

---

2. We accept Pull Requests that are tied to issues or change a very small number of lines. If you forget to open an issue with your Pull Request, the discussion will take place in the Pull Request - often leading to a very unstructured discussion. Contributions to the documentation and the tests are exempt from this rule, as they are quite literally self-documenting.

The encoding of this rule is relatively straight forward:

1. Scan the PR body (ghprbPullLongDescription in Jenkins) for the Fixes #(issue_number) pattern. If this cannot be found, either the PR breaks with the PR format requirements or there is no linked issue.
2. If there is no linked issue, check if all changes are within the doc folder or the line changes are small (e.g., max 30 lines). If there is no linked issue and the PR is not small or only addresses documentation, the PR violates CONTRIBUTING.md and should be rejected.

---

3. It is better to make small changes than large ones, as smaller changes usually have less bugs.

This is our line count distribution per file (including everything -- documentation, Python files, etc.):

We have no files longer than 1k lines. Doubling that for safety, any PR introducing a new file that is over 2k lines, is going overboard--whatever the file type--and should be rejected.

We can also adopt standard practices from e.g. https://github.com/marketplace/actions/pull-request-size-labeler. This example imposes a hard limit of 1k line changes by default--giving a warning when violated.

---

5. To your best ability, reflect your Pull Request's changes in your PR title (details go into the PR message). Follow this format: Added|Fixed|Removed|Updated your feature (for example, "Added PR instruction step 5").

This rule can be enforced by simply scanning the PR title (ghprbPullTitle in Jenkins) for the words "Added", "Fixed", "Removed" or "Updated". If these words are not in the title, the PR violates CONTRIBUTING.md and should be rejected.