WIP: Combine many remote to few remote module groups

[hjmjohnson]

WIP proof of concept for #6060: hierarchical remote module sub-groups.

Adds itk_fetch_module_group() and demonstrates consolidating 7 individual remote repos + SSIM into a single ITKRemoteAnalysis category repo with 8 modules and 1660 preserved commits. All 77 module tests pass locally.

CMake changes (~160 lines, 3 files)

• CMake/ITKModuleEnablement.cmake — add 4-level glob so Modules/Remote/Analysis/TextureFeatures/itk-module.cmake is discovered
• CMake/ITKModuleRemote.cmake — new itk_fetch_module_group() function: clones a category repo into Modules/Remote/<Category>/, respects freeze and tag override
• CMake/ITKGroups.cmake — sub-group request propagation: when ITKGroup_Remote_Analysis=ON, all modules in the Analysis directory are requested for build

Usage

# Enable the Analysis sub-group (clones ITKRemoteAnalysis repo)
cmake -DITKGroup_Remote_Analysis=ON ...

# Modules without EXCLUDE_FROM_DEFAULT build automatically:
#   IsotropicWavelets, PerformanceBenchmarking, RANSAC, StructuralSimilarity

# Modules with EXCLUDE_FROM_DEFAULT need explicit enable:
cmake -DITKGroup_Remote_Analysis=ON \
      -DModule_TextureFeatures=ON \
      -DModule_BoneMorphometry=ON \
      -DModule_BoneEnhancement=ON \
      -DModule_Thickness3D=ON ...

Test results (77/77 pass)

Module	Tests	Status
BoneEnhancement	2	Pass
BoneMorphometry	4	Pass
IsotropicWavelets	2	Pass
PerformanceBenchmarking	2	Pass
RANSAC	3	Pass
StructuralSimilarity	32 (GTest)	Pass
TextureFeatures	25	Pass
Thickness3D	2	Pass

What's NOT in this PR (future work)

• The ITKRemoteAnalysis repo is local only — needs ISC org repo creation and push
• The .remote.cmake currently points at a local path; will be updated to GitHub URL
• CI for the category repo (shared workflow) not yet configured
• Python wheel packaging for the category repo
• Other categories (IO, Filtering, Mesh, etc.) follow the same pattern

[thewtex]

I think it would be helpful to bring these modules into the ITK repository. But not dump them in a different repository, which complicates ownership and maintenance. Or, create a Remote Module Group, that groups the individual repositories.

[dzenanz]

Adding them to the main repository would make sense too, especially for the more well established ones. If doing so, we would need to expand on the concept of "Review" module (which was the path to entering the main repository in the past), including building everything into python packages.

[hjmjohnson]

For the remote modules for which we have strong evidence that only the core developers maintain them, I would 100% support bringing them into the ITK repository. That is an enormous maintenance burden relief! I understand the rationale behind the remote modules, but the implementation realities are that it is an extraordinary developer burden.

[thewtex]

I am not sure why effort is being put into consolidating the modules into a single module without bring the modules into ITK. If the rationale that it is an extraordinary developer burdern for ITK developers to maintain all the ITK Remote Modules as Remote modules (and the assumption is that ITK core developers should maintain all Remote Modules, which I did not intend to be the case), then bring them into the ITK repository. Part of the rationale behind remote modules is that non-ITK core developers can create and maintain them outside the ITK repository. This is lost with such an ITKRemoteAnalysis repository.

[hjmjohnson]

rejected, completely different approach will need to be looked into.

[hjmjohnson]

Superseded by #6085, which implements the inline-ingest strategy that reviewers requested in the discussion above (bring modules into the ITK repository rather than consolidating them into a separate group repo).

Keeping this PR closed and leaving all prior comments visible — they are the direct motivation for the new approach.