[cgal] add eigen3/tbb/ceres/openmesh features, split qt-svg out of qt

[N'yoma Diamond (nyoma-diamond)]

This PR adds standalone opt-in features for several of CGAL's optional third-party libraries, and fixes the existing qt feature to only depend on what CGAL's Qt integration actually requires.

Closes #48042 (requests an eigen3 feature and points out qt is overspecified).
Closes #10736 (clarifies intent/expectation to properly enable CGAL's TBB support).

New/changed features:

Feature	What it adds	Notes
eigen3	eigen3	Previously only obtainable by enabling qt, which has nothing to do with Eigen3
qt	qtbase[widgets]	Dropped eigen3 (see above) and qtdeclarative (never referenced by CGAL's Qt6 GraphicsView. Verified by reading CGAL_SetupCGAL_Qt6Dependencies.cmake, which only ever touches OpenGL/OpenGLWidgets/Widgets, plus optional Svg)
qt-svg	qtsvg, requires qt	Split out because CGAL declares Svg via OPTIONAL_COMPONENTS, not as a hard requirement of Qt support
tbb	tbb	Enables CGAL::TBB_support for CGAL's parallel algorithms
ceres	ceres	Enables CGAL::Ceres_support, used in mesh-processing optimization (e.g. angle/area smoothing)
openmesh	openmesh	Enables CGAL::OpenMesh_support, an alternative mesh data structure usable with CGAL's BGL-based algorithms

usage now documents the exact CMake needed per feature, since CGAL never links any of these automatically. Every one of CGAL's optional third-party integrations is opt-in per-target by design, matching what CGAL's own example CMakeLists.txt files do.

Design choices / caveats

• Per-target opt-in, not auto-detection. [CGAL] Enable CGAL_LINKED_WITH_TBB #10736's original ask was for the port to auto-detect TBB and enable it if present. This wasn't implemented as literally requested: It would violate the maintainer guide's "ports must not be path dependent" rule. A port's installed output/behavior must not silently change based on what else happens to be installed. Explicit per-feature opt-in (as done here) keeps cgal's behavior deterministic regardless of install order, and matches CGAL's own upstream design: Every one of its roughly 15 CGAL_*_support.cmake modules (Eigen3, TBB, Ceres, OpenMesh, OpenCV, METIS, and GLPK, among others) is opt-in per-target via an explicit include() + target_link_libraries(), not auto-enabled.

• find_package(... CONFIG REQUIRED) in usage, not QUIET. CGAL's own examples use QUIET (no REQUIRED) because they need to configure across arbitrary environments where the optional dependency may or may not exist at all. That's the wrong pattern for usage's audience: If you've enabled cgal[tbb] (etc.) via vcpkg, the dependency is guaranteed to be installed, so a silent find_package failure only masks real misconfiguration (wrong triplet, broken toolchain file). CONFIG also avoids a real hazard, beyond simple correctness. CGAL bundles its own legacy FindTBB.cmake (a raw TBB_ROOT-based module predating oneTBB) on CMAKE_MODULE_PATH, and CMake tries Module mode before Config mode by default. Without CONFIG, a machine with stray TBB_ROOT/TBB_ARCH_PLATFORM env vars from an unrelated install could silently hijack discovery away from vcpkg's package. Verified all five (Eigen3Config.cmake, TBBConfig.cmake, CeresConfig.cmake, OpenMeshConfig.cmake, and Qt6Config.cmake) are actually installed by vcpkg's respective ports.

• CGAL_setup_CGAL_Qt6_dependencies() alone is not sufficient. It links CGAL::CGAL, CGAL::Qt6_moc_and_resources, and Qt6::OpenGLWidgets with the INTERFACE keyword, which (per CMake semantics) only propagates to further consumers of your target: It doesn't reach an executable's own link line. usage documents linking those three explicitly as well, confirmed by hitting LNK2001 unresolved external symbol ...GraphicsItem::metaObject without it.

• openmesh, ceres, tbb, eigen3, and qt/qt-svg were each individually built and run against real upstream CGAL examples (Polygon_mesh_processing/examples for TBB/Ceres, BGL/examples/BGL_OpenMesh for OpenMesh, Solver_interface/examples for Eigen3, and a TriangulationGraphicsItem/QGraphicsView program for Qt), confirming actual execution rather than a successful configure step alone. This caught both the INTERFACE-linkage issue above and confirmed vcpkg's ceres package sets the legacy uppercase CERES_FOUND variable that CGAL_Ceres_support.cmake checks for.

• METIS/GLPK/OSQP/OpenCV/ITK were investigated but not added in this PR. They follow the identical simple pattern, but I didn't build/run/verify them the same way, and some (ITK, OpenCV) are heavy dependencies. Happy to follow up separately if there's interest.

Checklist

• Changes comply with the maintainer guide.
• SHA512s are updated for each updated download.
• The "supports" clause reflects platforms that may be fixed by this new version, or no changes were necessary.
• Any fixed CI baseline and CI feature baseline entries are removed from that file, or no entries needed to be changed.
  • The existing cgal[qt]:arm64-linux=cascade entry is unrelated to this change and left as-is.
  • Added cgal[qt-svg]:arm64-linux=cascade. qtbase:arm64-linux=fail and qtsvg:arm64-linux=cascade already confirm the same cascade path, and qt-svg depends on both cgal[qt] and qtsvg directly.
• All patch files in the port are applied and succeed.
• The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.
• Exactly one version is added in each modified versions file.

[Billy O'Neal (BillyONeal)]

GPT 5.6 Sol reports:

• The license expression omits MIT, although the installed CGAL/Classification/ETHZ headers are covered by upstream's exact MIT text in Installation/LICENSE.RFL.

Would you consider nyoma-diamond#2 ?