APE 1: Number is gone once reserved (naming chaos fix 2)

[pllim]

Motivation: Asking people to put a number in APE proposal filename too early and then changing the number last minute can cause merge conflict (for another open APE proposal) and confusion (for everyone else).

Case study:

• APE 24: Astropy Affiliated Packages with pyOpenSci (now APE 22) #87 (advertised as APE 24 for many months but merged as APE 22)
• APE 22: Public API #85 (advertised as APE 22 that can now never be)

But why are we renaming? To prevent gaps in accepted APE listing (e.g., the still open #14 and the missing APE 11 in the list of accepted APEs).

But are gaps really a big deal? In PEP (Python), they don't do re-numbering. And maybe neither in NEP (NumPy).

Proposed solution: As long as APE author follows the rules and use the next available number properly, the number is considered taken and cannot be reused. If the proposal is rejected, it either appears as a gap in the README or CoCo can say that APE number was rejected. Exception can be made to re-use a number if the proposal PR is closed as invalid/spam. If APE author uses an invalid number, reviewer would point that out very early in the review process (I think that is already status quo at the time of writing this PR).

Pros: No more numbering confusion.
Cons: Might end up with a lot of gaps in the listing of accepted APEs. For example, people will keep wondering what happened to APE 11 like we do with Windows 9.

Alternative:

• APE 1: Proposal filename should be descriptive (naming chaos fix 1) #96

More discussion: https://groups.google.com/g/astropy-dev/c/7Tnx7S3aGP4

[pllim]

Lots of support for this one, so taking it out of draft.

[eteq]

This is clearly the winner, so merging this over #96

[eteq]

@ceb8 volunteered to update the readme in this repo to reflect this change. Thanks!