zombienet-sdk-tests: fall back gracefully when CARGO_WORKSPACE_ROOT_DIR is unset

[Thiago316316]

Fixes the panic reported in #6906: build.rs unwraps CARGO_WORKSPACE_ROOT_DIR, an env var only supplied by this repo's .cargo/config.toml — absent in environments that don't apply it (e.g. remote-build tooling)

Root cause: build.rs had env::var("CARGO_WORKSPACE_ROOT_DIR").unwrap(). That variable isn't a cargo built-in — it only exists because this repo's .cargo/config.toml defines it under [env]:
CARGO_WORKSPACE_ROOT_DIR = { value = "", relative = true }
Cargo applies [env] entries automatically for a normal in-tree build, which is why it works for most of us locally. Your build path (/home/bkontur/cargo-remote-builds-aaa/...) looks like a remote-build tool that snapshots the source elsewhere and builds it there — in that kind of setup .cargo/config.toml's [env] section isn't necessarily applied, so the var is genuinely absent, and the old code just panicked instead of handling that.

What I confirmed before writing the fix:

• Reproduced your exact panic locally, by temporarily disabling .cargo/config.toml and clearing the crate's generated metadata files (so build.rs couldn't skip past the code path that needs the var).
• Confirmed via cargo tree that this variable is used in exactly one place (find_wasm()), and it's only ever an optimization — "if a runtime wasm blob is already built somewhere, reuse it instead of rebuilding" — so it's safe to degrade gracefully instead of panicking.

The fix: workspace_root() (new function on build.rs) now tries CARGO_WORKSPACE_ROOT_DIR first (unchanged behavior when it's present), and if that's absent, derives the workspace root by walking up from CARGO_MANIFEST_DIR — which cargo guarantees unconditionally for every build script — looking for the top-level Cargo.toml that contains [workspace]. That mirrors what cargo itself does to find a workspace root, so it doesn't depend on this crate's fixed depth in the tree.

Closes #6906.

[Thiago316316]

@bkontur Would appreciate a look when you have a chance — and if you're able to, a T18-zombienet_tests label would help it clear CI's check-labels gate.