feat: support shell expansion in dprint.path

[dsherret]

Supports a dprint.path setting that uses shell expansion, such as "dprint.path": "$(yarn bin dprint)". As before, a dprint.path from the workspace settings must be approved before it's run.

• On macOS and Linux, the dprint.path setting is interpreted by the shell (ex. $(yarn bin dprint) or $HOME/bin/dprint). Previously this happened to work because everything was double quoted when launched with a shell, which applied to the arguments too. Now the arguments (ex. config file paths) are single quoted so they're passed as-is, and an executable found in node_modules or on the path is launched without a shell.
• On Windows, cmd.exe doesn't support command substitution, so the extension runs each $(...) in the dprint.path setting itself (in the folder's directory) and uses its trimmed output. A shell is still used to launch dprint so that an npm dprint.cmd resolves, but the command and its quoted arguments are now provided as a single command line, which also avoids Node's DEP0190 warning about passing arguments with the shell option.

The launch logic is in a new getCommandLaunchInfo function that's used for the editor service, editor-info/-v, and the language server.

This also allows using dprint installed with Yarn Plug'n'Play (no node_modules folder) via "dprint.path": "$(yarn bin dprint)" on macOS and Linux. On Windows, yarn bin dprint resolves to the package's bin.cjs script in that case, which can't be launched directly.

SECURITY: Note that this ask for approval before executing so the extension doesn't run commands in config files without asking.

Closes #38
Closes #45

[DetachHead]

fyi this broke the workaround i was using to achieve the same result when using the pypi version of dprint.

i won't bother opening a separate issue because i have another workaround (dprint/dprint#859 (comment)), and i don't think it's really dprint's responsibility to fix this. see astral-sh/uv#15800 (comment)

[dsherret]

Fixing: #189