iceoryx2-pal-posix-qnx8 always needs a C toolchain (bindgen+cc), breaking consumption from repos with their own hermetic C++ toolchain

## Summary

`iceoryx2-pal-posix-qnx8` (vendored from `qorix-group/iceoryx2`, `MODULE.bazel:192-195`, no `crate_features` set in the `crate.annotation`) always builds its `socket_macros.c` shim via `bindgen`+`cc` unless the crate's own `libc_platform` feature is enabled — which it currently isn't, for any consumer.

## Where

`iceoryx2-pal/posix/build.rs` (in the vendored fork):
```rust
#[cfg(not(feature = "libc_platform"))]
fn main() {
...
let target_os = std::env::var("CARGO_CFG_TARGET_OS").unwrap();
if target_os.as_str() == "none" { return; }
#[cfg(not(target_os = "android"))]
if target_os != "android" {
// bindgen over posix.h, then cc::Build().file("src/c/socket_macros.c")
...
}
}
```
This isn't QNX-specific — it runs for essentially every real `target_os` (Linux included) whenever `libc_platform` is off. The crate's own `Cargo.toml` doc comment on `libc_platform` says enabling it "simplifies cross-compilation since bindgen is not required anymore," at the cost of only supporting "a subset of the supported platforms."

## Impact

Bazel's toolchain resolution is invocation-global, not scoped per bzlmod module. A consuming repo that registers its own (deliberately minimal/hermetic) C/C++ toolchain for unrelated C++ code ends up having that same toolchain used to compile this crate's `socket_macros.c` too — which fails if that toolchain's sysroot doesn't have full POSIX headers. Downstream symptom: `eclipse-score/kyron#166` (reproduced there via `communication`'s hermetic `gcc_toolchain`).

## Suggested direction

For non-QNX targets (Linux at least), consider publishing/aliasing a build of `iceoryx2-pal-posix-qnx8` with `crate_features = ["libc_platform"]` set in the `crate.annotation` — the `libc` crate is pure-Rust FFI declarations for Linux, so this should avoid the `bindgen`/`cc` build-script path (and the toolchain collision) entirely for that platform. Whether `libc_platform` is viable for the QNX target too (i.e. whether `libc`'s QNX support covers everything `iceoryx2-pal-posix` needs) would need checking separately — the doc comment's "only a subset of platforms" caveat suggests it might not be safe to flip on unconditionally for QNX.

## Not investigated here
Whether a `select()`-based alias (QNX gets the current bindgen/cc build, other targets get `libc_platform`) is feasible at the `crate.annotation`/BUILD-alias level in this repo's setup, or whether it needs to be a wholly separate `crate.spec` entry.

Read MODULE.bazel:192-195 and the vendored iceoryx2-pal/posix/build.rs, then check the crate's Cargo.toml documentation for the libc_platform feature. Determine whether a crate annotation or BUILD alias can select libc_platform for non-QNX targets while retaining bindgen and cc for QNX. Done means consumers with hermetic C++ toolchains no longer build the POSIX C shim on supported non-QNX targets.

Written by the indexing model from the issue text.