Document towncrier rendering release process

(This is a “sub-issue” of #11847)

In v4.3 I did a very awkward towncrier approach, but we should update the release instructions with a better process. Here’s a proposal @bsipocz , @Cadair, @pllim and I discussed out-of-band in an infrastructure telecon:

1. At the time of an RC, the release manager should look over the rendered changelog and look for issues like things being in the wrong section or changelog entries being too long. If they see issues, they should ask the maintainer “can you shorten or maybe put this in the what’s new? please make the PR to do that into main, and we’ll backport to the release branch” But they should not run towncrier to clean up the fragments for an RC
2. As a “last before release” (i.e., within 24 hr or so of release) step, the release manager should make a PR into the release branch that runs towncrier. It should then be merged just before released.
3. As a post-release step, the commit from step 2 should be forward-ported to main

For bugfix releases, just do 2-3, although the release manager may want to do some of the step 1 items in a PR just before release.

If we agree with that process, this should get written up into the release procedures docs.

[saimn]

The process seems fine to me. We should try to improve things before PRs are merged, so maybe add some instructions in https://github.com/astropy/astropy/blob/main/docs/changes/README.rst about using a concise style and maybe some guidelines as well on the expected phrasing ? There is already an example but it comes from Numpy and does not reflect our expectations I think.

[astrofrog]

The release docs have been refactored in https://github.com/astropy/astropy/pull/12755 and I think towncrier is now adequately described. Please feel free to open a follow-up issue or PR if the current towncrier instructions are not sufficient.