Display IEnumerables and IDictionaries in debugger prettily (with "Raw View" available)

[JustinGrote]

Resolves #1633

Adds a "Raw View" expandable to the variable pane much like the C# variable provider to hide "noisy" properties of IEnumerable/IDictionary.

[SeeminglyScience]

Awesome :) thanks for this! In your screen shot it shows a $true without color. Is that new with this change? or just something separate we need an issue for?

[JustinGrote]

Awesome :) thanks for this! In your screen shot it shows a $true without color. Is that new with this change? or just something separate we need an issue for?

Pretty sure that's separate, let me check without

[JustinGrote]

Awesome :) thanks for this! In your screen shot it shows a $true without color. Is that new with this change? or just something separate we need an issue for?

Pretty sure that's separate, let me check without

Yep, it is, opened issue PowerShell/vscode-powershell#3703

[SeeminglyScience]

LGTM, thanks again!

[andyleejordan]

Ditto #1636 (comment)

[andyleejordan]

What tests can we add to cover this @JustinGrote?

[JustinGrote]

I would say test both an ienumerable and an idictionary and verify that:

1. The object display contains all necessary properties
2. The "raw view" variable display contains what you would expect to see from an idictionary/ienumerable
3. Test a derived idictionary with additional properties/methods and make sure they show up similarly under "Raw view" instead of the direct collection

[JustinGrote]

Other test length updates were because their "view" has changed to summarize under the "Raw View" header

[JustinGrote]

@SeeminglyScience please re-review, code has changed a little to clean up the "Raw View" header, but this is mostly net-new tests. Thanks :)

[andyleejordan]

@JustinGrote I just added a commit with a couple cleanups. Namely I took out the new AssertDebuggerStoppedCommand and just made the existing AssertDebuggerStopped optionally accept a CommandBreakpointDetails, and I used the GetVariables(scope) helper I'd previously introduced to shorten your (lovely!) new tests.

[andyleejordan]

Awesome work Justin!

[JustinGrote]

@andschwa thanks, I actually originally wrote it with the optional parameters but I wasn't sure if that was muddling up the original AssertDebuggerStopped with too many code paths, hence the separate function for clarity. All good though!

[andyleejordan]

It made sense to me cause they're all doing the same thing: asserting the debugger stopped, and then optionally asserting it stopped on the right line (or command).