fix(frida): propagate cc's environment when building the test harness

[kkuehl]

Problem

crates/libafl_frida/build.rs invokes cl.exe directly to link test_harness.dll, but only forwards compiler.args() from the cc crate and drops compiler.env():

let compiler = cc::Build::new().cpp(true).file("test_harness.cpp").get_compiler();
let mut cmd = std::process::Command::new(compiler.path());
let cmd = cmd.args(compiler.args())... // compiler.env() is never applied

Outside a Visual Studio developer shell the process environment has no INCLUDE/LIB, so on Windows the build fails:

test_harness.cpp(1): fatal error C1034: stdint.h: no include path set

This forces Windows consumers of libafl_frida to build from a vcvars-initialised shell, even though cc itself locates MSVC without one (it compiles src/gettls.c fine in the same build).

Fix

cc already resolves the MSVC toolchain (vswhere/registry) and exposes the environment it would use via Tool::env() (pub fn env(&self) -> &[(OsString, OsString)]). Forward it to the direct cl.exe invocation:

.envs(compiler.env().iter().map(|(key, value)| (key, value)))

Verification

Built a Windows consumer (x86_64-pc-windows-msvc) of this crate from a plain PowerShell — no vcvars:

• before: test_harness.cpp(1): fatal error C1034: stdint.h: no include path set
• after: test_harness.dll is produced and the crate links successfully

No behavioural change on Unix; the extra environment is empty there.

[kkuehl]

The orkserver/libafl-fuzz CI failure is unrelated to this change: that fuzzer has #![deny(clippy::all)] and clippy 1.98 flags the late-initialized let scheduler; in uzzers/forkserver/libafl-fuzz/src/fuzzer.rs (
eedless_late_init) on current main.

I cherry-picked the same fix from #3926 (2f62ce0 -> �9c13de1) so this PR is green standalone. Once #3926 lands, this commit becomes a no-op.