Consider no longer using the PR consistency checking script for astropy core (or rethink)

While working on doing a v5.0.5 release I have noticed that the PR consistency scripts now return a lot of issues that are not issues:

* When maintaining 5.0.x and 5.1.x only the changelog rendering from 5.1.x gets forward-ported to main, so e.g. a PR merged labelled as 5.0.4 will actually not appear in the 5.0.4 section of the changelog if it was also backported to 5.1.x, but instead in the next 5.1.x release (we were ok with this decision back when we set up towncrier, I just mean that the scripts here don't recognize that).
* The changelog rendering happens during the release process and so the scripts can't easily check right now the rendered changelog until the last minute - currently this causes a lot of warnings about missing changelog entries.

In addition I spent a while just adding manual merges to the script, but haven't actually encountered any real issues.

Now that we have a pretty robust system for backporting and generating the changelog, and that we check for changelog entries being present in PRs at the time when the PR is open, and furthermore that we can just check for PRs labelled 'Still Needs Manual Backport' I don't think the scripts here are really needed anymore (for the core package).

Would we be happy to switch for astropy core to just saying that one should check for PRs still requiring manual merging? This would drastically reduce the burden of doing bugfix releases.

If we want to continue using the scripts, we are going to have to rethink how the checks are done re: LTS releases and so on.

Start by reading the PR consistency checking scripts and the documented astropy core release process. Compare their checks with the existing backport, changelog, and “Still Needs Manual Backport” workflow. Done means the project has decided whether to remove or redesign the checks and has an agreed implementation scope.

Written by the indexing model from the issue text.