PowerShell SDK should support easier invocation of PowerShell that is hidden from the debugger and that ignores `$PSDefaultParameterValues` and `*Preference` variables

Summary of the new feature/enhancement

When people build non-module tools that use the PowerShell SDK, they ultimately need to invoke some PowerShell commands. For tools are meant to function as a black box, the PowerShell commands that the tool invokes…

1. …should be hidden from the PowerShell debugger (so that breakpoints do not trigger on tool internals);
2. …should not pick up on user parameter preferences defined in $PSDefaultParameterValues;
3. …should not pick up on user invocation preferences defined in $*Preference variables;

This needs to be very, very easy so that tools can work as they were designed, without changes in behavior because of user preferences, and without the PowerShell debugger tripping on non-user code that is meant to be internal.

For a related discussion that highlights what tool makers need to think about in detail, see this comment in issue #2121 of PowerShell\vscode-powershell. That discussion also shows the scaffolding that is required to do something that should be very simple and supported in the SDK via a few flags.

Proposed technical implementation details (optional)

Any public interface that allows users to build PowerShell commands piecemeal (i.e. AddCommand, AddParameter, AddScript, AddArgument, etc.) and then invoke them needs to support invocation options that:

• hide the command(s) from the debugger;
• ignore $PSDefaultParameterValues;
• automatically apply default values for any common parameters that are not explicitly used.

~That’s not very specific, so obviously more investigation would be necessary to identify where to create these options so that they can be used via public interfaces, and where the options would need to be plumbed through the PowerShell runtime so that toolmakers get the results they expect.~

Update copied from discussion below:

To achieve this goal, S.M.A.PSInvocationSettings will be extended with a DebuggerHidden property, which would ensure the commands were hidden from the debugger, and a IgnorePreferenceVariables property, which would ignore $PSDefaultParameterValues and $*Preference variables. Programmers using the SDK can pass their PSInvocationSettings instance into S.M.A.PowerShell.Invoke, and with the new settings properly plumbed through the runtime, they won’t have to worry about user preferences impacting internal APIs.

[KirkMunro]

ISE seemed to do OK. It managed, manipulated state and debugged multiple runspaces both local and remote.

ISE isn’t that advanced as far as IDEs go, and it is still susceptible to internal behavior that can be unintentionally manipulated by use of $PSDefaultParameterValues, breakpoints, and $*Preference variables. PowerShell itself suffers the same problem. It just doesn’t show up that often, but regardless of the frequency, SDK users should be able to use the runtime in a way that internals are kept internal.

[BrucePay]

@KirkMunro Why not just use a separate runspace.