#662 GTK3V2MAIN: Clang -Wcast-function-type-strict finds ~90 pre-existing GTK callback-cast instances not covered by GCC's check

[Allen D Byrne]

Discovered while implementing Phase 10 of the GTK3V2MAIN quality plan (the -Wcast-function-type/etc. warning ratchet, SF #661): under GCC, -Wcast-function-type is genuinely zero for owned code (only vendored app/tools/halibut/charset/iso2022.c has instances), matching what Phases 4-6 originally verified and fixed. But Clang applies a distinct, stricter sub-check under the same flag name -- -Wcast-function-type-strict -- that Phase 4-6's original GCC/-Wextra-based verification never exercised.

Rebuilding the whole project under Clang with this sub-check enabled surfaces ~90 pre-existing findings across ~25 owned-code files, entirely in the GTK3 wlib layer (button.c, drawcontrol.c, menu.c, appwindow.c, list.c, text.c, toggle.c, print.c, pulldnmenu.c, combobox.c, and about 15 more). All are the same pattern: a GTK/GLib signal-connect or callback function being cast to a generic callback typedef (e.g. GCompareFunc, GtkCallback) whose parameter list doesn't exactly match the real handler's signature -- an extremely common, generally-safe idiom in GTK C code, and the same underlying pattern the project already has a blanket compiler-suppression for on the incompatible-pointer-types warning (see the "-Wno-incompatible-pointer-types" comment in PlatformSettings.cmake: "GTK3 type-system pointer casts throughout the codebase rely on the same suppression").

Not fixed as part of #661/Phase 10 -- 90 instances across 25 files is too large for what was meant to be a mechanical ratchet phase. Currently PlatformSettings.cmake only promotes -Werror=cast-function-type under CMAKE_C_COMPILER_ID STREQUAL "GNU" (GCC), specifically to avoid breaking the Clang-based CI jobs (c-tests-linux-clang, c-tests-macos, c-tests-sanitizers) on this pre-existing gap.

Needs a deliberate decision, same as the missing-field-initializers precedent (SF #660): either (a) fix the callback signatures properly (likely via small trampoline/wrapper functions per callback, or correcting the cast target types), or (b) add an explicit, documented suppression for this specific Clang sub-check alongside the existing -Wno-incompatible-pointer-types suppression, accepting it as the same class of idiom. Not silently ignored either way -- tracked here.