Add a snippets pane

[zadjii-msft]

This adds a snippets pane, which can be a static pane with all your snippets (sendInput actions) in it. (See #17329)

This pane has a treeview with these actions in it, that we can filter with a textbox at the top.

Play buttons next to entries make it quick to run the command you found.

Bound in the default actions with

        { "command": { "action": "splitPane", "type": "snippets" }, "id": "Terminal.OpenSnippetsPane", "name": { "key": "SnippetsPaneCommandName" } },

re: #1595

---

TODO, from 06-04 bug bash

• Snippets pane doesn't display some "no snippets found" text if there aren't any yet
• open snippets pane; find a "send input"; click the play button on it; input is sent to active pane; begin typing
• I can open an infinite amount of suggestions panes
  • I'm closing this as by-design for now at least. Nothing stopping anyone from opening infinite of any kind of pane.
  • This would require kind of a lot of refactoring in this PR to mark a kind of pane as being a singleton or singleton-per-tab
  • Okay everyone hates infinite suggestions panes, so I got rid of that
• Ctrl+Shift+W should still work in the snippets pane even if focus isn't in textbox
• open snippets pane; click on text box; press TAB key;
  • If you press TAB again, I have no idea where focus went
• some previews don't work. Like ^c ("input": "\u0003")
• nested items just give you a bit of extra space for no reason and it looks a little awkward
• UI Suggestion: add padding on the right side
• [Accessibility] Narrator says "Clear buffer; Suggestions found 132" when you open the snippets pane
  • Note: this is probably Narrator reading out the command palette (since that's where I opened it from)
  • We should probably expect something like "Snippets", then (assuming focus is thrown into text box) "Type to filter snippets" or something like that

[zadjii-msft]

[zadjii-msft]

• Snippets pane doesn't display some "no snippets found" text if there aren't any yet

Adding

in the latest commit.

[carlos-zamora]

Found a few more bugs while testing:

• "close pane" keybinding --> crash (looks like we're failing to check IsReadOnly()?)
• pressing space on an item "selects" it, but doesn't open it. Honestly, I'd treat space as enter
• When snippets are open, pressing tab goes like this: textBox -> treeView -> unknown -> unknown -> textBox (we've cycled). Idk where those two unknown are, but we should remove them.
• I'd expect enter/space on the tree view item itself to invoke the "play" button. It's just a dead key rn. Pretty annoying to have to tab to "play" button to get it injected imo.
• Clicking on a root node (i.e. "git..." which expands to a bunch more options) doesn't actually expand it! We need to click on the chevron. It'd be nice if we could just click on the item itself and it would expand.

Accessibility issues:
The UIA tree has a bunch of problems in it. I'm gonna list a bunch of changes we need here, but the ones that are labelled with a "❌" are the ones that are most urgent. We might get flagged with the others during an a11y pass, but I'd be fine with them as a follow-up.

• pane and custom have no a11y name
  • MG: As discussed, punting this out of this review, considering it seems all the panes have that? Maybe it's the Border inside panes, but it's not unique to this PR. The SUI has two!
• ❌ tree items have the name TreeViewNode... so screen readers just read TreeViewNode as you move focus from one node to another... so please please please give them a name (should be the displayed text from the text blocks). Key thing here is that all text that's displayed on the screen must be read by a screen reader.
• ❌ button doesn't have a name. It should have the same name as the tooltip
• We should probably announce "open snippets pane" when we open the snippets pane. It's a context shift we should make clear to the user (especially if they're visually impaired).

Some misc. things I also found during code review:

• Do we want to x:Load="False" the whole snippets pane too?
  • MG: Nah, cause it's just instantiated on demand anyways. It's not in the startup path.

Some funny things that can/should/maybe/idk be fixed(?):

• I get that it's a snippets pane and we can/should be allowed to open an infinite amount. I'm still a bit concerned about having a bunch of snippets panes open and not knowing where the input will be sent to
• Maybe we shouldn't allow a snippets pane to be opened from a snippets pane?...
• 
• I somehow got into a state where pressing the "open snippets" keybinding will open TWO snippets panes at once! SUPER SNIPPETS!
  • update from 5 minutes later: oh huh, it suddenly stopped doing that... that was weird
  • MG: Uh, okay? I'll just assume this was nothing then?

Ok, I think I've bug bashed this enough. I have yet to review SnippetsPaneContent files, but this should be plenty to keep you busy for at least a morning.

[carlos-zamora]

x:Load="False"?

[zadjii-msft]

Meh? We're already instantiating the entire pane at runtime (so loading it isn't on the startup path). I guess this would save us instantiating like, 4 controls at runtime, but idk

[zadjii-msft]

Addressed the feedback in #17330 (review), save for one thing that isn't unique to this PR, and the infinite snippets pane thing. I guess everyone hates that, so I'll do something dumb to go prevent that.

[carlos-zamora]

Omg. This feels really nice with the keyboard. Thank you!

Found one more bug:

• first invocation doesn't work
  • open a new tab
  • open snippets pane using a keybinding (NOT command palette)
  • tab to an entry of interest
  • tab to the play button on it
  • invoke the play button (i.e. space, enter, click)
  • BUG: input is not sent anywhere

These are more design-related changes. I'd love it if they made it in this PR, but at the very least, they should be tracked and/or discussed for this milestone imo:

• We can get into a state where the tab only contains a snippets pane. Should that be allowed?
  • in this state, snippets cannot be injected into a terminal in another tab (which is a good thing imo)
• Aside from the situation above, input should always go somewhere, right? If that's not the case, we should maybe display a warning at the top of the pane or maybe in a teaching tip? Have the warning say "no active terminal detected"?
  • really, I'm just trying to avoid the play button being a dead button. Because when that happens, I just get confused and sad.
• Should we add a short description at the top of the Snippets pane? On one hand, it'll probably be ignored by most people. On the other, it could be a nice/short/quick intro to the feature.
• Double click a tree view item to send input? 👀

Requesting changes still, but once we get the last a11y stuff done and you fix that one bug above, we should be good. So close! But it's great!

[carlos-zamora]

📝 This is what this looks like now