no_std: add PathBuf abstraction

[mparkachov]

Summary:

• Add steel::path::PathBuf wrapper and expose it from steel-core, plus a std-only path separator constant and component collection support in path.rs.
• Replace std::path::PathBuf usage across steel-core and dependent crates with steel::path::PathBuf, updating public APIs and call sites accordingly (compiler/modules, VM, parser, fs/http, docs, LSP, REPL, CLI).
• Make env_home, glob, xdg, and which optional deps gated by the std feature in Cargo.toml.

Testing:

• cargo test --all -> ok

[mattwparas]

So my only concern with this change is that there are a bunch of public APIs that expect a std PathBuf, so this change would be breaking. In particular in the engine API. I suppose one fix would be to have the std feature just be a type alias for the standard PathBuf as to not break any callers?

[mparkachov]

I didn't though about this. I've addressed it by making steel::path::PathBuf a type alias to std::path::PathBuf when std is enabled. That removes the breaking change for public APIs (including engine API): callers still see and pass a std::path::PathBuf in std builds.

What changed from the original wrapper approach:

• crate::path::PathBuf is alias under std and a lightweight string-backed type only under no_std.
• removed the extension trait approach call sites now use standard methods (to_path_buf, to_str) so no extra imports
• no_std PathBuf implements std‑like methods (as_path, as_os_str, to_path_buf, to_str, etc.) to keep the call sites consistent.

[mparkachov]

Merged master and resolved conflicts.

[mparkachov]

no progress