languages: Fix poetry environment discovery on Linux (#47100)

Closes #47098 

The root cause of this issue is related to how `Poetry` (and the
upstream `pet-poetry` library) handles path hashing. While perhaps it's
an upstream behavior, we can easily fix it on the Zed side.

The related code are

https://github.com/zed-industries/zed/blob/7ce845210d3af82a57a7518e0abe8c167d60cc6a/crates/languages/src/python.rs#L1181-L1211

In my debugging, I found that `worktree_root` takes the form
`/home/user/project`, but `config.workspace_directories` often ends up
as `/home/user/project/`(with a trailing slash). Normally this wouldn't
be an issue, but `Poetry` generates environment names based on the hash
of the absolute path. Since the hashes for `/home/user/project` and
`/home/user/project/` are different, `pet-poetry` fails to find the
environment.

The fix is straightforward: we just need to ensure the trailing `/` is
removed so the hashes match.

Release Notes:

- Fixed poetry environment not discovered on linux

crates/languages/src/python.rs

@@ -1200,7 +1200,16 @@ impl ToolchainLister for PythonToolchainProvider {
         config.workspace_directories = Some(
             subroot_relative_path
                 .ancestors()
-                .map(|ancestor| worktree_root.join(ancestor.as_std_path()))
+                .map(|ancestor| {
+                    // remove trailing separator as it alters the environment name hash used by Poetry.
+                    let path = worktree_root.join(ancestor.as_std_path());
+                    let path_str = path.to_string_lossy();
+                    if path_str.ends_with(std::path::MAIN_SEPARATOR) && path_str.len() > 1 {
+                        PathBuf::from(path_str.trim_end_matches(std::path::MAIN_SEPARATOR))
+                    } else {
+                        path
+                    }
+                })
                 .collect(),
         );
         for locator in locators.iter() {