Better handling for non-QWERTY keyboards

[17cupsofcoffee]

Fixes #151 (or tries to, at least...)

As per the discussion in that issue and on Discord, this PR changes Key to represent key position rather than key meaning, and introduces several new APIs to complement this:

• KeyLabel represents keys based on their labelling in the current keyboard layout (similar to how Key worked before). It implements Display, to make it easy to use in a game's UI (and as a bit of a hint that you should probably be using this type rather than Key in user-facing scenarios).
• input::get_key_with_label finds the physical key that has a particular label in the current keyboard layout.
  • Example use case: mapping a config file to input bindings
• input::get_key_label returns the layout-specific label for a given physical key.
  • Example use case: displaying button prompts in game

I would have liked to add a label field to Event::KeyPressed and Event::KeyReleased as well, but that would be a breaking change, so I'll do it as part of 0.7.

why tho

Currently, all Tetra games are broken out of the box if the player has a non-QWERTY keyboard layout. This is much more common than I realized (e.g. France and Belgium use AZERTY as standard)!

You can get around this by asking the player to change their layout, or by allowing them to configure input bindings themselves, but it's not a good initial impression - especially if you're in a game jam scenario, where people are likely to just move onto another game rather than spend ages trying to get yours to work.

This feels like the nicest solution to me, because it gives decent behaviour without any extra effort on the developer's part (i.e. the game work on all keyboards, but UI prompts might be incorrect), while giving them the tools to make a really polished implementation via KeyLabel.

[tesselode]

I haven't tried it yet, but from reading your description and the code, this looks like a sensible API to me. 👍

[17cupsofcoffee]

Nobody's told me this is a totally crazy idea yet, so 🚀