This change starts the host_env isolation plan by moving the shared OS-facing helpers out of rustpython-common into a dedicated rustpython-host-env crate. The goal is to make host access explicit in crate dependencies and reduce accidental leakage of host-only code into sandbox-oriented builds.

• New rustpython-host-env crate

  • Adds crates/host_env to the workspace
  • Introduces rustpython-host-env as the home for shared host abstractions with no Python runtime dependency
  • Exposes the migrated modules through a small crate root:
    • os
    • crt_fd
    • fileutils
    • windows
    • macros

• Moved host-specific shared code out of rustpython-common

  • Relocates the existing shared host helpers from crates/common/src/ into crates/host_env/src/
  • Removes these modules from rustpython-common
  • Drops nix, windows-sys, and widestring from rustpython-common now that those dependencies belong to the new host crate

• Dependency graph updated

  • Adds rustpython-host-env to workspace dependencies
  • Wires both rustpython-vm and rustpython-stdlib to depend on rustpython-host-env
  • Re-exports the crate from rustpython-vm as vm::host_env for internal/external consumers

• Import migration in VM / stdlib / top-level consumers

  • Replaces direct uses of rustpython_common::{os, crt_fd, fileutils, windows, suppress_iph} with rustpython_host_env (or crate::host_env / vm::host_env where appropriate)
  • Updates representative host-facing call sites across:
    • VM stdlib modules
    • stdlib crate modules
    • top-level binary entrypoints
    • examples

Example of the migration pattern:

// before
use rustpython_common::crt_fd;
let code = rustpython_vm::common::os::exit_code(exitcode);

// after
use rustpython_host_env::crt_fd;
let code = rustpython_vm::host_env::os::exit_code(exitcode);

This keeps the behavioral surface unchanged while making host-environment coupling explicit at the crate boundary, which is the foundation for tighter sandbox enforcement in follow-up work.