Restore CI Linux made useful

[kwankyu]

This PR is the closed PR #39009 rebased on the current develop branch.

Test CI run (as of 10.6.rc0): https://github.com/kwankyu/sage/actions/runs/14017325314
compare with the status quo: https://github.com/sagemath/sage/actions/runs/14008119416

To improve the situation with the CI infrastructure, this PR:

• Restore jobs removed by Disable broken and outdated CI #39467 (and its sequel CI: Remove broken Linux Mint and openSUSE runs #39670), which made CI Linux useless.

• Added comments untangling obscure code in CI-related files, for those poor guys who ever attempt to read the files for whatever reasons.

• While doing the cosmetic changes, a bug (about -uninstall targets) was found build/make/Makefile.in, which is fixed here.

  To test, do

  $ ./configure --enable-dot2tex | grep dot2tex
  $ make build | grep dot2tex
  $ ./configure --disable-dot2tex | grep dot2tex
  $ make build | grep dot2tex
  

• Fixed some jobs in the CI-linux workflow that fail because of duplicate artifact names.

• Reduced supported platforms under testing. This is how to properly modify the list:

  • first edit tox.ini (find DEFAULT_SYSTEM_FACTORS)
  • run tox -e update_docker_platforms
  • commit the changes

• "optional" and "experimental" jobs now run upon "standard" docker images, instead of "maximal" ones, to avoid "out of runner space" error.

• Renamed "Reusable workflow for Docker-based portability CI" to "Workflow for Linux portability CI" for short name and made it runnable through github interface to facilitate testing specific platform by adding "workflow-dispatch" calling docker.yml.

  Test: https://github.com/kwankyu/sage/actions/workflows/docker.yml

• Added helpful comments and updated the developer doc

• Reimplemented .ci/write-dockerfile.sh so that simplified Dockerfile is generated for present and future stability

• Turned off failing jobs in "CI Linux incremental"

• Removed seemingly useless subprojects/factory directory to eliminate certain git warnings.

• Turned off "standard-sitepackegs" and "standard-constraints_pkgs-norequirements" jobs as they fail on (almost) all platforms.

Test CI with a PR: to be prepared.

The main objective of this PR is to solve issues with the workflow "CI Linux" such that a failure on a platform reveals solely some problem of sage built on the platform, but not a problem of the CI infrastructure. After this PR, hopefully, each of failing platforms should be tackled individually. If a platform fails, perhaps we should

1. decide first whether to support the platform or not.
2. if the platform is supported, open a github issue for it.
3. if the platform is not supported, then remove it from the "master list of supported linux platforms" in tox.ini.
4. if a supported platform constantly fails but no PR for the issue is present, then we may turn it off (by commenting it out) until fixed.

I suggest discontinuing support (at least in CI) for Linux releases that have been past their EOL (end of life or end of support by the distributor) for more than 2 years.

Only decent platforms according to the CI results should be listed in https://github.com/sagemath/sage/wiki/Sage-10.6-Release-Tour#availability-and-installation-help.

The following diagram shows how packages are installed for each of CI jobs:

                _prereq | standard package | optional package | experimental package | "ptest" runs
-----------------------------------------------------------------------------------------------
"minimal"        SSSSSS | ---------------- |                  |                      | yes
"standard"       SSSSSS | SSSSSSSSSSS----- |                  |                      | yes
"maximal"        SSSSSS | SSSSSSSSSSS----- | SSSS             |                      | yes 
"optional"       SSSSSS | SSSSSSSSSSS----- | ------------     |                      | yes
"experimental"   SSSSSS | SSSSSSSSSSS----- |                  | ----                 | no

where "S" represents system package and dash "-" represents Sage package. Hence

• In the test results of "minimal" job, we can examine how well standard sage packages behave with sage.
• In the test results of "standard" job, we can examine how well standard system packages behave with sage.
• In the test results of "maximal" job, we can examine how well optional system packages behave with sage.
• In the test results of "optional" job, we can examine how well optional sage packages behave with sage.
• In the test results of "experimental" job, we can examine how well experimental sage packages behave with sage.

📝 Checklist

• The title is concise and informative.
• The description explains in detail what this PR is about.
• I have linked a relevant issue or discussion.
• I have created tests covering the changes.
• I have updated the documentation and checked the documentation preview.

⌛ Dependencies

[github-actions]

Documentation preview for this PR (built with commit 820c7c6; changes) is ready! 🎉
This preview will update shortly after each push to this PR.