Minimize the number of projects under lts-team/packages

To the extent that it is reasonable, the number of projects under the lts-team/packages group should be minimized. This consists of, for each project:

• assess whether there is a maintainer or team repo for the package already on Salsa
• assess the suitability of the maintainer or team repo for LTS/ELTS work (i.e., is it DEP14 conformant)
• if it is not conformant, make a note in packages.yml that documents the fact that we work in a fork or a new project for technical reasons (probably something like "DEP14: maintainer repo non-conformant, so work in a new project")
• if it is conformant, approach the maintainer or team with a request to integrate any work present in our specific project and not in the maintainer or team repo* (that request should include an offer of assistance for implementation of comprehensive Salsa CI, if that is not already implemented)
• if the maintainer accepts the request, perform the integration action***
• if the maintainer rejects the request, make a note in packages.yml that documents the fact that we work in a fork or a new project at the request of the maintainer (probably something like "RoM: LTS/ELTS work is not desired in the maintainer repo, so work in a fork")

* The "ideal" solution here is to push branches and tags for LTS/ELTS versions directly into the maintainer or team repo**. However, if there is a divergence (because we forked and created different branches in the fork or because we created an entirely new project) then this may instead entail something like using gbp import-dscs and targeting the appropriate branches in the maintainer or team repo.

** Further note that some maintainers or teams implement access control for their projects (i.e., not necessarily every DD on Salsa is able to push automatically). This is considered reasonable here. That is, "we must request access to push our changes to the maintainer/team repo" does not mean "and therefore we fork or create a new project". As specified in our Git workflow documentation, we only fork or create a new project when the maintainer is using an unconventional and/or difficult to work with branch structure (e.g., non-DEP14) or when the maintainer specifically states that LTS and/or ELTS work is not welcome directly in the repo.

*** The integration action consists of the steps described in note * above, and also determining if the project under lts-team/packages is no longer necessary. Depending on whether the maintainer accepts all LTS/ELTS work or only LTS work, the appropriate updates must be made to the vcs (and vcs_elts, if applicable) to point the maintainer repo. If all branches/tags/commits have been pushed to the maintainer repo, then the project under lts-team/packages is no longer necessary and an issue should be created along the lines of "Archive and delete unused lts-team/packages/{project}" and assign the issue to @roberto and @santiago

(insert checklist of all projects under lts-team/packages here)

If you are interested in working on this issue, then please discuss your interest and intentions with the coordinators before doing any work.

/cc @santiago