Add macOS clang-scan-deps support

[mini-1235]

Summary

Add central macOS support for Clang's C++ dependency scanner in generated CMake, Catkin, and Ament CMake recipes.

Problem

CMake 3.28 and newer may scan C++20 sources for module dependencies. On macOS, conda-forge activates a target-prefixed compiler such as arm64-apple-darwin20.0.0-clang++, while clang-tools installs the scanner as the unprefixed $BUILD_PREFIX/bin/clang-scan-deps.

CMake derives the toolchain prefix from the compiler name and therefore fails to discover the packaged scanner, eventually attempting to run CMAKE_CXX_COMPILER_CLANG_SCAN_DEPS-NOTFOUND.

Changes

• Add a macOS-only clang-tools build requirement to CMake, Catkin, and Ament CMake recipes.
• Match the clang-tools major version to cxx_compiler_version, with * as the fallback when the compiler version is undefined.
• Leave Python-only and dummy recipes unchanged.
• In both Unix CMake templates, verify that $BUILD_PREFIX/bin/clang-scan-deps exists and pass it through CMAKE_CXX_COMPILER_CLANG_SCAN_DEPS.
• Place the central scanner argument before package-specific CMake arguments so packages can still override it explicitly.

The scanner path does not enable module scanning by itself. CMake continues to decide whether to scan based on the C++ standard, generator, compiler support, policy settings, and CXX_SCAN_FOR_MODULES properties.

Validation

• Generated ros-rolling-ur-controllers recipes with this Vinca checkout.
• Confirmed the macOS recipe renders clang-tools 19.*.
• Confirmed dependency solving selects Clang 19.1.7 and clang-tools 19.1.7.
• Removed the package-specific CMAKE_CXX_SCAN_FOR_MODULES=OFF workaround for the focused verification.
• Built ros-rolling-ur-controllers successfully on osx-arm64; Ninja completed nine dependency-scanning steps and the log contained no CMAKE_CXX_COMPILER_CLANG_SCAN_DEPS-NOTFOUND in the successful build section.

The Vinca unit, lint, and formatting baselines were not run as part of this focused verification.

[mini-1235]

Note that unprefixed clang scan deps is also supported in a newer cmake Kitware/CMake@5537b3d, but we are currently pinning cmake to 3.* due to RoboStack/ros-jazzy#40 (comment)

[mini-1235]

fyi @Tobias-Fischer

[traversaro]

That seems quite a bit of complexity. Perhaps at this point is just easier to unpin cmake so we use the latest cmake, and fix any possible remaining error?

[mini-1235]

I can remove the *.sh.in changes if we are able to upgrade the cmake version, and just keep the changes in main.py. I can try unpinning cmake today in my ros-rolling PR and see how the CI goes

However, based on your previous comment, I think the root cause might actually be related to vinca setting:

$Env:AMENT_PYTHON_EXECUTABLE="${env:CONDA_PREFIX}\python.exe"

It seems like this may need to be changed to:

$Env:AMENT_PYTHON_EXECUTABLE="${env:CONDA_PREFIX}/python.exe"

My main question is whether Windows is ready for us to bump the cmake version now. Do you happen to remember any of the details around the previous issue?

Admittedly, I a not very familiar with Windows, and I don't have a Windows machine available to test this locally :(

[mini-1235]

Maybe I was wrong, looks like the error comes from ament-cmake-python a3577e9