Add elliptic curve, graph, and polytope databases to Meson builds

[cxzhong]

Pure Meson/meson-python builds currently do not provide the standard
elliptic_curves, graphs, and polytopes_db data packages. In editable
builds, missing Cremona data breaks calls such as EllipticCurve(...).rank(),
while missing graph data breaks constructions that consult the strongly regular
graph database.

This PR:

• adds elliptic_curves 0.8.1, graphs 20210214.p0, and
  polytopes_db 20170220.p0 as Meson wraps;
• generates cremona_mini.db and the 23 rank* databases from the elliptic
  curve package sources;
• installs the 4 graph database files and 18 polytope database files directly
  with no additional generator;
• owns fallback install targets in the main project so meson-python
  --skip-subprojects does not omit them;
• detects traditional installations below the Python data directory and
  SAGE_LOCAL/share;
• installs regular-wheel data below sys.prefix/share and makes editable
  builds search generated or source data in the appropriate Meson tree;
• preserves SAGE_DATA_PATH, GRAPHS_DATA_DIR, POLYTOPE_DATA_DIR, and
  the dedicated elliptic database path overrides; and
• declares all three data packages as sagelib prerequisites to avoid a
  parallel-build configure race.

The Cremona failure was observed in
https://github.com/sagemath/sage/actions/runs/30950404368/job/92130761402.
The graph database failure was observed in
https://github.com/sagemath/sage/actions/runs/32445437036/job/96664097240.

Tests performed after conda activate sage:

• configured a clean Meson build with no system copies and verified all three
  fallback subprojects;
• verified SQLite integrity and all 38,042 class / 64,687 elliptic curve rows;
• verified all 23 generated rank* files byte-for-byte against the 0.8.1
  package;
• verified all 18 polytope and 4 graph files remain parent-owned install targets
  and map to the corresponding meson-python wheel data directories;
• configured against the conda SAGE_LOCAL and verified all three fallbacks
  are skipped;
• verified editable lookup for generated elliptic data and source graph and
  polytope data;
• src/bin/sage -t --warn-long 5.0 --random-seed=214100764227587711308816290927482221446 src/doc/de/tutorial/introduction.rst src/sage/features/databases.py src/sage/geometry/polyhedron/palp_database.py;
• src/bin/sage -t --warn-long 5.0 --random-seed=178778358194368484633470764324423043070 src/sage/combinat/matrices/hadamard_matrix.py src/sage/features/databases.py src/sage/graphs/graph_database.py src/sage/graphs/isgci.py;
• Ruff, ty, Meson format, Python compile checks, Ninja dry run, and
  git diff --check.

📝 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

None.

[github-actions]

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

[dimpase]

Good idea. Same should be done for polytopes_db

[antonio-rojas]

Wasn't it planned to make pypi packages for sage databases? I think this would be better than turning the sagelib meson build into sage-the-distro-reborn.

[tobiasdiez]

Wasn't it planned to make pypi packages for sage databases? I think this would be better than turning the sagelib meson build into sage-the-distro-reborn.

Yes, that's the plan and I agree it would be a better solution. On the other hand, nobody yet found the time to do this, so perhaps the subprojects are the most pragmatic way for now?

cc @orlitzky

[orlitzky]

What is the actual problem with editable builds? We already have # needs database_ellcurves or # needs database_graphs for these things. AFAIK they are working fine, otherwise factoring out the interfaces to pypi would be a higher priority.

Splitting the remaining ones is not trivial but it could be done in a few days. It would be a much better use of time to e.g. eliminate the stupid sage.databases.SQLDatabase wrapper around the EC/graph databases.

[dimpase]

actually, I have been playing a bit with git-lfs lately, and it would drastically simplify this kind of stuff for developers: just check in all these databases into lfs of a repo, and get them pulled when needed.