feat: add regression tests for instrument hooks

[not-matthias]

• Fixed build on MUSL targets (added compat.h header)
• Using zig cc compiler (based on clang) to easily cross-compile

[art049]

This doesn't totally match what we want.
We need to check the build of this library against multiple compilers: clang, GCC, and a few of their versions. I think using zig cc instead of those compilers is a big discrepancy with what happens in the consumers
Checking against multiple targets is interesting, though, and a good first step. However, if that becomes a blocker to support those with the compilers, we should prioritize checking aarch64 and x86_64.

To use newer versions of GCC and clang, you can use the Docker images and the GitHub actions integration:
https://hub.docker.com/_/gcc

Didn't find anything for clang/LLVM, but I guess we can find something

[art049]

Actually for clang/llvm: https://hub.docker.com/r/silkeh/clang
Edit: this might also be of interest https://apt.llvm.org/

[not-matthias]

@art049 Added compilation tests of the C example using clang+gcc with the docker images you linked. Works quite well.

Also disabled the mandb to make the tests with valgrind a bit faster.

[art049]

Looking much better!

            -Wno-builtin-declaration-mismatch \
            -Werror \

            -Wno-incompatible-library-redeclaration \
            -Werror \

Is it expected to have different flags for each compiler? It might complicate each integration if we have to conditionnaly swp flags.
In this workflow we could just have a var INSTRUMENT_HOOKS_CFLAGS

[not-matthias]

Looking much better!

            -Wno-builtin-declaration-mismatch \
            -Werror \

            -Wno-incompatible-library-redeclaration \
            -Werror \

Is it expected to have different flags for each compiler? It might complicate each integration if we have to conditionnaly swp flags. In this workflow we could just have a var INSTRUMENT_HOOKS_CFLAGS

The reason we had this, was because clang and gcc have different errors/flags. But I realized that we could remove the root issue (passing the wrong types to printf) to solve this.

Now we only get an error in clang about the format string security which can be ignored. I also added it to GCC to be sure it works (but we don't need it).

EDIT: Also enabled -Wall to catch more warnings that would also be exposed in the integrations. This way we can whitelist them manually.

[art049]

we can group those in a global variable or a define to clearly state that these are the expected flags but otherwise lgtm