Modifying ChordKeybinding to support multiple chords

[toumorokoshi]

Hi! I'm very interested in getting support for keychords of more than two keys (see #6966), so here's a PR to kick off my interest.

I think a see a general strategy to get there, but before I get too deep, I wanted to get a quick review on my approach.

In general, it looks like many parts of the code base are built on the concept of a "firstPart" and a "chordPart" for key chords. I think the first step is modifying all of these to support an arbitrary number of parts. Once that is done, the logic needs to be modified slightly to iteratively run through each part rather than stop at the first two.

As a start to support key chords of longer than two parts,
modifying the internal structure of ChordKeybinding to not specifically
call out two parts.

@alexandrudima you are the assignee of the ticket mentioned. Would you mind giving me some feedback on this approach?

Thank you!

[msftclas]

All CLA requirements met.

[alexdima]

👍 This makes sense.

The next step should be to adopt multiple chords in the ResolvedKeybinding subclasses. I've left TODO@chords where this should happen.

[toumorokoshi]

@alexandrudima I think I have everything for the first major change. I've made the choice to modify some interfaces slightly in a more future direction (return an array of parts vs a chord part). So you'll see a lot of changes there.

Also I'm switching all bindings to ChordKeybinding rather than SingleKeybinding because it removes the conditional code significantly. Curious about your thoughts.

[toumorokoshi]

@alexandrudima if you have a chance can you take a look at this PR? I've gone as far as I feel comfortable at this point, as I've seen giant prs become harder and harder to merge.

[alexdima]

@toumorokoshi, I agree this PR has grown large enough.

I've only found a couple of bugs where some map invocations were not properly bound to this in WindowsNativeResolvedKeybinding.getParts and WindowsNativeResolvedKeybinding.getDispatchParts, but other than that this was very high quality, and I thank you for that!

I've also tweaked a bit the label calls and having done so, I plan to further refactor those classes and raise some methods to their abstract parent class.

I've left TODO@chords in two places:

• where user bindings are parsed (i.e. allow users to write keybindings with N chords in their keybindings.json)
• where bindings are converted for dispatching (i.e. allow dispatching of N chords)

The first one is rather easy to tackle, the second one is a bit more work, as the KeybindingResolver needs to change a bit.

[toumorokoshi]

Awesome, thanks so much! Darn, I thought I caught all the bound errors... I'll be more careful.

Thanks for the TODOs! I'll take a look at those next.