Enable wt to inherit the working directory

[zadjii-msft]

Summary of the Pull Request

Enable wt to inherit the working directory from the commandline and Explorer.

References

PR Checklist

• Closes Starting directory no longer respected #878
• I work here
• [n/a?] Tests added/passed
• [n/a] Requires documentation to be updated

Detailed Description of the Pull Request / Additional comments

I don't feel totally confident in this change. This changes two scenarios, and the run dialog one I'm not super happy about:

1. Explorer address bar: wtd -> Results in the Terminal being launched in the current path of explorer.
2. From a commandline shell: wtd -> Results in the Terminal being launched in the current path of shell.
3. Windows Search: Win, Term (or anything to get to "Windows Terminal)" -> Results in the Terminal being launched in startingDirectory
4. Run Dialog: Win+R, wtd -> Results in the Terminal being launched in %USERPROFILE%

• this is the CWD of the run dialog
• maybe unexpected?

5. Windows Search: Win, wtd -> Results in the Terminal being launched in C:\Windows\System32

• technically, the Start menu is invoking the wtd commandline here.
• maybe unexpected?

[qqkookie]

How about adding "-d" (no argument) to let wt ignore StartingDirectory entry and start in current working directory of parent process, and "-d~" option to force wt to start in %USERPROFILE% directory?

[zadjii-msft]

Honestly I'm not sure I like this change at all. Especially when you try to reconcile it with #3495. Say we had both PRs merged - how does a user open the terminal in their startingDirectory from the run dialog? wt --actuallyUseStartingDirectory? That's silly.
With commandline args, we could pretty easily solve the "use the CWD" problem with wt -d .. However, we can't solve the run dialog and start menu starting in %userprofile% and c:\windows\system32 (respectively).

@qqkookie I'd take a look at #3495, since that's got a much lengthier, complete proposal for commandline arguments.

[zadjii-msft]

After sitting with this a couple weekends now, I hate it. As mentioned above, it results in unexpected behavior in two cases that work well today, and solving those side-effects of this PR doesn't reconcile well with #3495. I'm going to close this PR, and use arguments proposed in that PR as the definitive answer.