add support for Pico Keyboard

[qufb]

These changes introduce a new input method for the Pico Keyboard, a PS/2 peripheral for the Sega Pico, allowing emulation of games that use this peripheral:

• Keyboard Pico - Kantan Waku Waku Keyboard
• Keyboard Pico 2 - Sawattemiyou! Yoiko no Hajimete Keyboard
• Kitty to Minna no Keyboard Pico - Kitty to Minna no Hajimete no Keyboard!
• Kibodeu Piko

Requires a dedicated input update function for frontends, implemented in my libpicofe pull request (https://github.com/irixxxx/libpicofe/pull/1). Once that one is merged, I can update the submodule repository in this one.

Since the original input handling used a bitmask for mapping keys to events, the larger number of keys required for this peripheral had to be implemented in another way, in this case it uses an array that is associated with a single input binding type (IN_BINDTYPE_PICO_PS2).

In order to sufficiently test the keyboard, I found that activating most minigames requires interacting with the Storyware via the pen button. Since these games don’t render a pen cursor, I added a pen position overlay to guide a player, disabled by default.

Tested under Linux with the generic SDL frontend.

Limitations

• Key bindings are hardcoded at compile time (see ./platform/common/input_pico.h and ./platform/common/inputmap_kbd.h), missing logic to allow reading and storing to configuration file.
• Kibodeu Piko has an issue where key break is not handled correctly: each key only registers a single time, subsequent key presses aren’t registered.

For more context, see the following documentation: https://qufb.gitlab.io/writeups/pico#keyboard-pico

[LibretroAdmin]

While I have nothing against merging this, is there a libretro implementation of this? It doesn't seem like there is. The libretro project doesn't really do anything with standalones, although that won't preclude us from merging something for this specific repo since staying in lockstep with upstream is at least somewhat beneficial.

It still is a big omission though if no libretro implementation is made for this.

[qufb]

Upstream doesn't seem to be maintained, according to this comment: https://github.com/notaz/picodrive/pull/133#issuecomment-1019356392

He points to another fork, but libretro is based on the notaz repo. I'm not sure how the irixxxx fork relates with libretro, but if you prefer, I can open the pull request against that one.

Although I haven't looked into that code path, I don't mind giving a try with the libretro implementation. There will be some shared code nevertheless, so I'd prefer for someone to have a look at the base code first before working on the libretro implementation (I would open another pull request for that).

[LibretroAdmin]

Alright, well, @irixxxx I think has administrator control over this repo too, so leaving it in his able hands. I'm fine with whatever for what it's worth.

[irixxxx]

Can we possibly move the PR to my repo? As it is right now, it's not libretro related, and it's easier for me since I can avoid cross-merging of features.

On 1st inspection, there are some minor scoping issues mainly with libpicofe (used by other projects as well) which I'd like to sort out before merging.

[qufb]

@irixxxx done, closing this one for now.