Move package `Status` and `AcceptDate` from `PackageInfo.g` files to a central "registry"

[fingolfin]

Right now, packages specify in their meta data whether they are accepted/deposited/submitted/... etc., and we don't really verify this. So in theory a package author could insert anything there.

It is also awkward that in order for a package to become accepted, it has to make a new release.

We should reconsider this. Logically, I don't think this state belongs into PackageInfo.g. Instead, I think we should store this data in a central place (e.g. in a JSON file in this repository, or whatnot). Moreover, I think the precise version of the package that was "accepted" should be recorded, not just the date of acceptance.

I've discussed this with Bettina Eick, and we'll discuss this further with the GAP council next time it meets, but in the meantime I wanted to record this idea here.

[fingolfin]

So how to get there? Some thoughts:

• create a script which extracts the relevant data and puts it into a JSON file (or whatever format we want)
• figure out a place where to store this file (probably as part of the package distro)
• optionally: for accepted packages, reverse engineer which version actually was refereed (based on the date)
• make related fields (Status, AcceptDate, CommunicatedBy) optional in the GAP package validator
• bonus feature: if the package validator detects that a package requires GAP 4.13 (or whichever version we introduce this change), then let it even warn if any of those fields are present, and suggest to remove them
• change the packagedistro scripts to scrub these fields from meta.json files and from package-infos.json files
• adapt GapWWW to not use these fields from package-infos.json, instead from the central
• adapt package list on website to not use this data but rather the new file in the package distro
• look for anything else that might process these and adapt it
• adapt PackageMaker to not output the removed fields anymore (but only after the first GAP with these changes was released; probably even only after quite some time passed)
• adapt the Examples package