Introduce a separate class for formatting shortcuts

[zoul]

Formatting a shortcut (ie. producing a string description of its modifiers or keys) should be refactored into a standalone clas. This will give use options (⌘^ or Command-Control, uppercase or lowercase, ASCII or Unicode) and is simply the right thing to do. Since formatting depends on the active keyboard layout (see the spec), it would be great to turn this into an explicit setting. That way we could then run automated formatting tests with various keyboard layouts – and we could also probably write automated tests for code that depends on shortcut formatting, such as shortcut validation (see #62).

The keyCodeString property could then be simply deprecated and later removed, or we could make it call a shared default formatter with the appropriate settings. The keyCodeStringForKeyEquivalent should be probably deprecated, since it’s only used during validation. It’s also used when somebody wants to assign a shortcut as a key equivalent of a menu item, but that use case would be better served directly by a category on NSMenuItem (maybe even bindable).

[zoul]

The TISCopyInputSourceForLanguage function looks interesting. We could wrap TISInputSourceRef into a MASInputSource class and create initializers like +inputSourceForLanguage: and +currentInputSource. The future MASShortcutFormatter class would then take an input source (MASInputSource*) as an argument, defaulting to +currentInputSource.