add accessibility help extension contributions pt

[meganrogge]

This includes:

• an accessibility help dialog implementation for each view with accessibleHelpContent
• an accessibility help hint that is applied to the view's aria label until a user opens the accessibility help dialog for that view. this required adding a new AcessibleViewInformationService to workbench/services so the view service can understand if an accessible view has been shown already in that layer
• resolves <keybinding:commandId> to the keybinding, if any, or a message and linked command to configure the keybinding

[alexr00]

Very cool! In addtion to my inline comments, why is the accessibilityHelpContent contribution only a string and not also a markdown string?

[meganrogge]

why is the accessibilityHelpContent contribution only a string and not also a markdown string?

done

addressed

[mjbvz]

Let's discuss how keybindings should be expressed at an API sync before merging this

[meganrogge]

To discuss in API sync:

1. Do we want to have syntax which allows just a command ID to be provided and resolved as a the command title, its keybinding (if any) or the link to configure the keybinding
2. Can we render the markdown such that a screen reader user doesn't have to navigate through [Configure a Keybinding](commandLink)?

[alexr00]

You have my approval, but I unchecked auto-merge since Matt wants to discuss at the API sync.

[meganrogge]

@mjbvz discussed with Jo at the API sync and he has signed off on what I'm doing for keybindings.

I will get feedback on and defer this part #210665:

Can we render the markdown such that a screen reader user doesn't have to navigate through Configure a Keybinding?