Add capability for KeyboardEvent.code + capture

[vidartf]

This:

• Adds the capability for KeycodeLayout to also use the code field from KeyboardEvents. It still allows for adding keyCode values to the map, both for backwards compatibility, but also since there are some keys that will not have a code value (it will be either an empty string or "Unidentified").
• Adds a map for code fields for EN_US.
• Adds a package with a widget for capturing keyboard layouts.
• Adds an example app for capturing keyboard layouts.
• Adds a fallback for mapping the key field from KeyboardEvents onto the list of "Special Keys" from the spec. This is only considered if there are no match for the event via the code/keyCode fields.

Resolves #74.

TODOs:

• Add tests for capture widget / example.
• Find a way to explicitly prompt for a key value for "Dead" keys. This might need some extra thought to catch corner cases. We should not try to capture Dead keys, as they are unsuitable for use in shortcuts.
• Seek out corner cases for layouts where isComposition is relevant. Capture any behavior in tests. Conclusion: Any compose use should be handled by the caller of the API.
• Figure out a pattern for adding other layouts. Should they be added to keyboard package, or to one or more separate language packs? Conclusion: Use in language pack or similar, not in core package.

[fcollonval]

Here is what I got using a fr-fr keyboard:

fr-fr layout

codes: {
  "AltLeft": "Alt",
  "AltRight": "AltGraph",
  "ArrowDown": "ArrowDown",
  "ArrowLeft": "ArrowLeft",
  "ArrowRight": "ArrowRight",
  "ArrowUp": "ArrowUp",
  "Backquote": "²",
  "Backslash": "*",
  "Backspace": "Backspace",
  "BracketRight": "$",
  "Comma": ";",
  "ControlLeft": "Control",
  "ControlRight": "Control",
  "Delete": "Delete",
  "Digit0": "À",
  "Digit1": "&",
  "Digit2": "É",
  "Digit3": """,
  "Digit4": "'",
  "Digit5": "(",
  "Digit6": "-",
  "Digit7": "È",
  "Digit8": "_",
  "Digit9": "Ç",
  "End": "End",
  "Enter": "Enter",
  "Equal": "=",
  "Escape": "Escape",
  "F1": "F1",
  "F10": "F10",
  "F11": "F11",
  "F12": "F12",
  "F2": "F2",
  "F3": "F3",
  "F4": "F4",
  "F5": "F5",
  "F6": "F6",
  "F7": "F7",
  "F8": "F8",
  "F9": "F9",
  "Home": "Home",
  "Insert": "Insert",
  "IntlBackslash": "<",
  "KeyA": "Q",
  "KeyB": "B",
  "KeyC": "C",
  "KeyD": "D",
  "KeyE": "E",
  "KeyF": "F",
  "KeyG": "G",
  "KeyH": "H",
  "KeyI": "I",
  "KeyJ": "J",
  "KeyK": "K",
  "KeyL": "L",
  "KeyM": ",",
  "KeyN": "N",
  "KeyO": "O",
  "KeyP": "P",
  "KeyQ": "A",
  "KeyR": "R",
  "KeyS": "S",
  "KeyT": "T",
  "KeyU": "U",
  "KeyV": "V",
  "KeyW": "Z",
  "KeyX": "X",
  "KeyY": "Y",
  "KeyZ": "W",
  "Minus": ")",
  "Numpad0": "0",
  "Numpad1": "1",
  "Numpad2": "2",
  "Numpad3": "3",
  "Numpad4": "4",
  "Numpad5": "5",
  "Numpad6": "6",
  "Numpad7": "7",
  "Numpad8": "8",
  "Numpad9": "9",
  "NumpadAdd": "+",
  "NumpadDecimal": ".",
  "NumpadDivide": "/",
  "NumpadEnter": "Enter",
  "NumpadMultiply": "*",
  "NumpadSubtract": "-",
  "PageDown": "PageDown",
  "PageUp": "PageUp",
  "Period": ":",
  "Quote": "Ù",
  "ScrollLock": "ScrollLock",
  "Semicolon": "M",
  "ShiftLeft": "Shift",
  "ShiftRight": "Shift",
  "Slash": "!",
  "Tab": "Tab"
}
modifiers: ["Alt", "AltGraph", "CapsLock", "Control", "Shift"]

[vidartf]

From discussion on the JupyterLab dev call today, the following points were discussed:

• The keyboard-capture package couldn't be used in the lab extension, as the settings form require React components to be used, so I am thinking of moving all the code there into the example. That would simplify concerns about adding a new package.
• @krassowski Suggested maybe only shipping en-US with the package, and putting other layouts elsewhere, for example similar to language-packs (or maybe together with them?).

[vidartf]

Note:

• There is a small change in the .keys returned by the default en-us keymap, as it now returns Control instead of Ctrl. The other APIs still accept Ctrl as a value.
• The features for supporting browser-base keyboard layout is marked as @alpha in the docstring / API extractor. I don't know what policy we have around this.