Allow means to avoid adding an absolute Cwd path to the workspace settings

[cegekaJG]

Prerequisites

• I have written a descriptive issue title.
• I have searched all issues to ensure it has not already been reported.

Summary

Our team's repositories all track our .code-workspace files to make sure people are working with the same settings. However, we obviously can't include an absolute path in the powershell.cwd setting because we can't ensure it will be the same between users. Unfortunately, there seems to be no way to avoid this issue, and worst case, we keep having to remove the automatically appended setting.

Proposed Design

I can think of 3 ways to circumvent this problem:

1. Add an option that, when opening a file in PS-language, recursively scan in the file's directory for a workspace setting file, going up a folder if nothing could be found. If one is found, pick the workspace directory the file is located in, (choosing the nearest if there are nested folders) and use that as the Cwd for the session.
2. Add an option that reads the Cwd path from a different file that can be included in the .gitignore. You could enforce it to be located in the same directory as the workspace settings.
3. Add an option that doesn't write the Cwd path into the settings, and just caches them instead, prompting the user to specify a folder every time after the cache is cleared.

[andyleejordan]

Agreed, it's been bothering me too. It seemed like an okay solution at first but the fact that it has to be absolute makes it very terrible. I think we could go with #3. I'm imagining the setting would be left available, but the extension would never write to it; instead, if prompted to choose X of Y workspace folders, we'll remember which by using Code's extension data API (it just wasn't wired up at the time).

[JustinGrote]

@andyleejordan I think this would be fairly simply possible that, rather than storing in workspace settings, store in the workspaceState Memento of the extensionContext as a key.

https://code.visualstudio.com/api/references/vscode-api#ExtensionContext

This would persist across reloads, it would be user-specific (so different people can have different local CWD paths) and would function the same as CWD does now, though for good UX we will probably also want to expose what workspace is the currently active one in the Powershell language menu and offer a button to change it that ties to the existing command.

[andyleejordan]

From what I remember when originally implementing, using that was more difficult than anticipated as we hadn't plumped through the context at the time. However, I think we've since made the extension context more readily available to classes in the client, sooo yes this is probably doable pretty easily now! Up-for-grabs if you want to take a at it...I'm trying to figure out how not to have to just merge the revert PowerShell/PowerShell#20042 to fix #4668.