ENH: Reimplement GDCMSeriesFileNames on gdcm::IPPSorter/Scanner (drop deprecated SerieHelper)

[hjmjohnson]

Reimplement itk::GDCMSeriesFileNames on the supported modern GDCM API (gdcm::Directory + gdcm::Scanner + gdcm::IPPSorter), dropping the deprecated gdcm::SerieHelper. Part of #6467.

Why

gdcm::SerieHelper is documented by GDCM as deprecated backward-compat code — "DO NOT USE this class, it is only a temporary solution for ITK migration from GDCM 1.x to GDCM 2.x … Instead see ImageHelper or IPPSorter." This PR moves GDCMSeriesFileNames to the supported API.

What changed

• Backend: gdcm::Directory (enumerate, honoring Recursive) → gdcm::Scanner (group by SeriesInstanceUID + detail tags; the series identifier replicates SerieHelper::CreateUniqueSeriesIdentifier) → gdcm::IPPSorter (geometric ImagePositionPatient-on-normal ordering). Lazy parse with a TimeStamp cache, so repeated GetSeriesUIDs/GetFileNames/GetInputFileNames calls no longer re-scan.
• Characterization tests (first commit, added while still on SerieHelper so they pin the pre-existing contract): single-series enumeration/grouping, geometric ordering reconstructs a valid uniformly-spaced volume, GetInputFileNames returns the first series, Recursive descent. Green on both backends.

Intentional behavior changes

• IPPSorter is strict. Duplicate-IPP and gantry-tilt acquisitions fail to sort; the input order is then left unchanged rather than fabricated. Whether these need first-class support — and whether SerieHelper's permissive strategy was correct — is tracked in Discussion: GDCMSeriesFileNames ordering edge cases (duplicate IPP, gantry tilt) and whether SerieHelper's permissive strategy is correct #6468. (Per maintainer direction, no SerieHelper fallback is ported in this PR.)
• AddSeriesRestriction now refines the series identifier (the documented and example intent, e.g. "0008|0021"), instead of delegating to SerieHelper's largely-inert file-restriction list.

Testing

All 89 ITKIOGDCM tests pass locally (series-reader, direction-cosine, compliance suites). pre-commit run --all-files clean. The vendored gdcm::SerieHelper is untouched (still used by GDCM's own code); a follow-up may remove it once upstream GDCM drops it.

[hjmjohnson]

@malaterre I have been looking at removing the "SerieHelper" dependency that is only kept around for ITK (according to the GDCM comments for SerieHelper). Your insights into the implications of the proposed change would be helpful.

[hjmjohnson]

@greptileai re: the P2 "LoadSequences/LoadPrivateTags are silently dead" (outside-diff comment) — addressed in 50dfb13. The two flags are intentionally inert with the gdcm::Scanner backend (the scan reads only the grouping/ordering tags). Rather than restore unsupported behavior, they're now documented as no-ops on both setters (Doxygen) and in the ITK 6 migration guide. Retained for source compatibility.

[greptile-apps]

Thanks for the pointer to 50dfb13. The resolution looks correct:

• The Doxygen on both SetLoadSequences and SetLoadPrivateTags now explicitly states "No effect with the gdcm::Scanner backend (retained for source compatibility)" — clear, accurate, visible at the call site.
• The migration guide entry covers it too: "SetLoadSequences/SetLoadPrivateTags have no effect… retained for source compatibility but no longer alter enumeration."

Documenting them as intentional no-ops rather than either silently dropping behavior or fabricating emulation is the right call. The gdcm::Scanner API simply doesn't expose sequence/private-tag parsing at scan time, so there's nothing meaningful to delegate to. P2 addressed — marking resolved.