fix(gemset): stop calling std::env::split_paths on wasm

[kjanat]

Gemset::env calls std::env::split_paths when GEM_PATH is set in the worktree shell environment. On wasm32-wasip2 that function is panic!("unsupported"), so the extension aborts inside language_server_command:

Failed to start language server "solargraph": error while executing at wasm backtrace:
   11: zed_ruby.wasm!std::sys::pal::wasip2::os::split_paths
   12: zed_ruby.wasm!std::sys::sync::once::no_threads::Once::call
   13: zed_ruby.wasm!std::sync::once_lock::OnceLock<T>::initialize
   14: zed_ruby.wasm!zed_ruby::language_servers::language_server::LanguageServer::try_find_on_path_or_extension_gemset
   15: zed_ruby.wasm!zed_ruby::language_servers::language_server::LanguageServer::language_server_command
Caused by:
    wasm trap: wasm `unreachable` instruction executed

After the trap wasmtime refuses every further call into the extension with wasm trap: cannot enter component instance, so all Ruby language servers stay down until Zed restarts. Introduced in #189.

Two commits:

1. Split GEM_PATH with a plain string split instead of std::env::split_paths.
2. Take the host OS from zed::current_platform() and use ; on Windows for the split and for both joins. The joins were hard-coded to : before, which produced values Ruby cannot read on Windows.

Tests cover gem home already present in GEM_PATH, GEM_PATH absent, and both cases on Windows.

Verified with cargo test, cargo clippy --all-targets, cargo fmt --check, and cargo build --target wasm32-wasip2.

[vitallium]

Thanks for fixing this issue!