build: Support both Clang and GCC toolchains

[felipek]

-Wno-stringop-truncation is a GCC-only warning option. Passing it
unconditionally broke the Clang build, which rejects it as an unknown
warning option (an error under -Werror). Make it GCC-conditional via a
generator expression.

Additionally add a Clang-only block that relaxes the Clang-specific
diagnostics triggered by the same strict flags (-pedantic, -Wconversion):
intentional GNU extensions (gnu11/gnu++17), "()" vs "(void)" prototypes,
and stricter implicit enum/integer narrowing and signedness checks. The
GCC build keeps its full strict -Werror warning set unchanged.

Verified clean (-Werror, 0 warnings) with Apple Clang 21 and GCC 15.2.0.

[felipek]

Hi @alexmohr @minminlittleshrimp please review this as follow-up to c840f29 - there is a very tiny incompatible change requiring gcc (brew) which is not great since people can use standard Apple/Xcode/clang tools with this minor cmake/make change. I have tested it both with GCC and Clang. Thanks!

[alexmohr]

Works for me with default cmake arguments thank you. Now that it works with clang we could update the brew file too, so it does not depend on gcc anymore?

[minminlittleshrimp]

IMHO we still support both, and in Apple case here clang still be fine right? homebrew with prevelent using gcc can also alternatively with clang?

I have check with local Clang and this change is valid, and I believe it good to go with the configuring.

Im also deploying 3 more pipelines for clang tidy clang format cppchecker and commit msg format checker s.a. requesting signoff or limit to 72 chars soem kind of, that can help strengthening the automation process

[alexmohr]

Yes we still support both with this PR, but as @felipek also mentioned already clang is pretty much the standard way on MacOS, so we could drop the gcc depedency from the brew file and compile it with clang per default. This will only affect users installing via homebrew and you still can build locally with GCC instead.

[felipek]

Hi @minminlittleshrimp @alexmohr yes clang is the Apple standard (llvm/clang are Apple originated projects anyway), gcc requires either brew/MacPorts or something similar. I think it is fine to keep support for both, but it is more testing/coverage, yes...