zephyr-sys: fix undefined __UINTxx_C macros under bindgen (#160)
Summary
On Ubuntu with libclang-15, bindgen fails to process Zephyr’s
kernel/internal/mm.h because of recently-added file-scope #if
directives that reference CONFIG_SRAM_BASE_ADDRESS. On boards whose
autoconf.h renders that value via __UINT32_C(...), the preprocessor
needs that macro defined before it reaches those #ifs.
GCC and clang normally emit __INTxx_C / __UINTxx_C as compiler
predefines, and Zephyr’s minimal libc <stdint.h> relies on that — the
public UINTxx_C(...) macros are simply redirected to the underscored
variants on the GCC/clang branch. The libclang used by bindgen does not
expose those predefines to its embedded preprocessor, so the #ifs in
mm.h fail with function-like macro '__UINT32_C' is not defined and
bindgen aborts.
This pulls in <stdint.h> at the top of wrapper.h and explicitly
defines the __INTxx_C / __UINTxx_C set, guarded with #ifndef so
that a toolchain which does surface them keeps precedence.
Background
The triggering upstream change is Zephyr commit eb805306186 (“sca: Fix
undefined behavior during preprocessing”), which moved mm.h‘s
evaluation of those Kconfig values into file-scope #ifs. Before that,
the macros only needed to be valid at the point of use, which happened
to work without this shim.
Test plan

 west build on an RP2040-class board (which exercises the
CONFIG_SRAM_BASE_ADDRESS = __UINT32_C(0x20000000) path) under Ubuntu
with the system libclang-15
 Existing CI continues to pass on other host/board combinations