itk: add build-itk.yml for riscv64 wheels - #4798

CMAKE_CXX_FLAGS is a flat string that CMake writes verbatim into the
generated ninja build command, which ninja then hands to /bin/sh -c.
The previous commit's -D_Float128=long double therefore split into
two shell words at the unescaped space ("-D_Float128=long" and
"double"), so every compile - including CMake's own compiler-ABI
check - failed immediately with "double: linker input file not
found", before CastXML/LLVM was ever reached. Escaping the space
(long\ double) keeps it one shell word, giving the compiler the
intended single macro definition.

The previous commit's -D_Float128=long\ double still failed: the
backslash-escaped space is meant to survive bash -> cmake -> ninja's
build.ninja -> sh -c as a single shell word, but CMake re-emits
CMAKE_CXX_FLAGS into the generated ninja rule without preserving the
backslash, so sh -c re-splits it into "long" and "double" and the
compiler rejects "double" as a bogus input file - exactly the same
symptom as before, confirmed in the real cp311 CI log (c++: error:
double: linker input file not found).

Writing the #define into its own header and pulling it in with
-include /work/float128-workaround.h avoids the whole quoting chain:
a path has no embedded space to lose, so there is nothing left for
any of those layers to re-split.

CMAKE_CXX_FLAGS is both forwarded to CastXML's --castxml-cc-gnu and used
directly by the real GCC build of ITK's own C++ sources. Text-substituting
_Float128 -> long double unconditionally collides with glibc/libstdc++'s
own separate template specializations for the two types under GCC
(redefinition of __iseqsig_type<...>, numeric_limits<long double>). Guard
the #define to __clang__ so it only affects the CastXML forwarding it was
written for.

CastXML's own Detect.cxx (detectCC_GNU()) runs the exact compiler+flags
array ITK's Wrapping/macro_files/itk_auto_load_submodules.cmake hands it
via --castxml-cc-gnu through the real GNU compiler (never Clang) with
"-E -dM -v <empty file>" appended, to dump its predefined macros for
castxml's own internal Clang parse of the real wrapping input files to
use. That macro mirrors CMAKE_CXX_FLAGS wholesale (confirmed against the
real itk_auto_load_submodules.cmake source at the pinned v5.4.7 tag:
set(_castxml_cc_flags ${CMAKE_CXX_FLAGS})), so the prior commit's
#ifdef __clang__ guard - added to keep the _Float128->long double
substitution off GCC's real build of ITK's own C++ library sources,
which also reads CMAKE_CXX_FLAGS directly - excluded it from this probe
just as much as from that real build, since GCC never defines __clang__
either way. Confirmed from the real cp311 CI log (job 130740385856) that
this reproduces the exact pre-workaround failure one leg over: the probe
never captures the override, so castxml's internal Clang parses
ITKCommonBase.cxx (and friends) with _Float128 still undefined, hitting
"unknown type name '_Float128'" in bits/mathcalls.h/wchar.h/stdlib.h --
on a head commit well after the guard commit, ruling out a stale build.

patches/itk/5.4.7/0001-castxml-scope-the-_Float128-workaround-to-the-cast.patch
moves the -include out of the string GCC's real library build consumes
(CMAKE_CXX_FLAGS itself, left alone) and into itk_auto_load_submodules.cmake's
own _castxml_cc_flags, right where that macro builds them up, guarded on
the workaround header actually existing. This reaches the castxml-cc-gnu
probe (and, directly, castxml's own internal Clang invocation, if it ever
uses this string on its own) without the real GCC build ever seeing it,
so the #define no longer needs the __clang__ guard that defeated the
probe - verified the patch applies cleanly against a fresh clone of the
real v5.4.7 tag, not guessed.