Build rabe with LLVM Fortran compilers

[krystophny]

Summary

• Add RABE_NETCDF_PROVIDER=auto|system|fetch.
• Build HDF5, NetCDF-C, and NetCDF-Fortran with the active Fortran compiler when the system netcdf.mod is not usable.
• Fetch NetCDF-C v4.9.2 and NetCDF-Fortran v4.6.1 by tag, and keep the fetched NetCDF-C link set to HDF5, zlib, and libm.
• Link rabe, the libneo shim, and test helpers through netcdf::netcdff and public module dependencies.
• This is the first step to enable autodiff on the Fortran side, so rabe can keep the Fortran stack instead of depending on the Python/JAX port.

Notes

lfortran configures and skips unsupported -w, but the build still stops in Quadpack module scanning. I filed the reduced upstream issue: lfortran/lfortran#11612.

No libneo PR was needed in this step. rabe uses its local libneo CMake shim, and this PR wires that shim to the compiler-matched NetCDF target.

Verification

Test fails on main

$ cmake --build /tmp/rabe-build-flang -j4
error: Semantic errors in .../libneo-src/src/nctools_module.f90
Cannot parse module file for module 'netcdf': Incomplete character literal

$ cmake --build /tmp/rabe-build-ifx -j4
.../libneo-src/src/nctools_module.f90: error #6404:
This name does not have a type, and must have an explicit type. [NF90_NOWRITE]

$ cmake --build /tmp/rabe-build-lfortran-clean -j4
ninja: build stopped: multiple rules generate _deps/quadpack-build/modules/quadpack_generic.mod.

Test passes after fix

$ cmake -S . -B /tmp/rabe-build-flang-review -G Ninja \
    -DCMAKE_Fortran_COMPILER=flang-new -DCMAKE_BUILD_TYPE=Debug
-- The Fortran compiler identification is LLVMFlang 22.1.5
-- Building NetCDF-Fortran for LLVMFlang
-- Build files have been written to: /tmp/rabe-build-flang-review

$ cmake --build /tmp/rabe-build-flang-review -j4
[311/311] Linking Fortran executable test/plot/plot_local_drift.x

$ ctest --test-dir /tmp/rabe-build-flang-review --output-on-failure \
    --parallel 4 --timeout 120 -L quick
100% tests passed, 0 tests failed out of 31

$ source /opt/intel/oneapi/setvars.sh >/tmp/rabe-ifx-setvars.log
$ cmake -S . -B /tmp/rabe-build-ifx-review -G Ninja \
    -DCMAKE_Fortran_COMPILER=/opt/intel/oneapi/compiler/2025.0/bin/ifx \
    -DCMAKE_BUILD_TYPE=Debug
-- The Fortran compiler identification is IntelLLVM 2025.0.4
-- Building NetCDF-Fortran for IntelLLVM
-- Build files have been written to: /tmp/rabe-build-ifx-review

$ cmake --build /tmp/rabe-build-ifx-review -j4
[311/311] Linking Fortran executable test/plot/plot_local_drift.x

Dependency fetch check

NetCDF Version:        4.9.2
Extra libraries:      -lhdf5_hl -lhdf5 -lm -lz
XML Parser:           tinyxml2 (bundled)
SZIP Write Support:   no
ZSTD Support:         no

Runtime checks not fixed here

$ ctest --test-dir /tmp/rabe-build-flang-clean --output-on-failure \
    --parallel 4 --timeout 120
80% tests passed, 8 tests failed out of 40
The following tests FAILED:
  16 - PlotFitFunctions (Subprocess aborted)
  34 - PlotAntiSigma (SEGFAULT)
  35 - PlotDeviationHelicalAntiSigma (SEGFAULT)
  36 - PlotHelicalAntiSigmaSmallAspect (SEGFAULT)
  37 - PlotDeviationPoloidalAntiSigma (SEGFAULT)
  38 - PlotLocalDrift (SEGFAULT)
  39 - GoldenRecordRun (Timeout)
  40 - GoldenRecordCompare (Not Run)

$ ctest --test-dir /tmp/rabe-build-ifx-clean --output-on-failure \
    --parallel 4 --timeout 120 -L quick
52% tests passed, 15 tests failed out of 31
The failing ifx quick tests abort with forrtl SIGSEGV.

[krystophny]

Merged main; resolved conflicts by dropping the local libneo shim (fetched libneo picks up the pre-existing netcdf::netcdff target) and made cross-library Fortran module dependencies PUBLIC so flang sees transitive module dirs; earlier test/benchmark check failures were runner billing errors that are since cleared.

[GeorgGrassler]

@krystophny I though of revifying this branch. At this point a combined approach (AD + "per-hand" adjoints where appropriate) seems most viable, but I noticed a possible tension of compiling the whole project with flang /enzym ... it might not be compatible anymore with f90wrap, which would cut the adjoint/AD being usable in Python (see jameskermode/f90wrap#378). One could of course write the bindings all "per-hand" (not my hands), but that seems tedious to keep in sync...