Feature/kbd boards

[JorgeGzm]

boards: follow the unified keyboard input in the two lvglterm configurations

Summary

This is the last of three parts. It names an application option, so it goes
with apache/nuttx-apps#3687

Those two cannot be green at the same time, and it is worth saying why
before anybody reads the CI. Each repository is built against the other's
master, and there is no way to pair two branches, so this one sees an apps
master where EXAMPLES_LVGLTERM_INPUT_KBD and SYSTEM_KBD do not exist
yet, and the apps side sees board configurations that still name the option
it renamed. The failures on both sides are confined to the normalisation
step of the same two configurations, and both go green once both are in.

The pair was verified together, see Testing.

The LVGL terminal used to have three input sources to choose from, one per
kind of keyboard, and now has two: touch, or any keyboard. The two in-tree
configurations that named the old option are updated here.

• Linum STM32H753BI. Beyond the rename, the configuration now enables
  UINPUT_KEYBOARD and SYSTEM_KBD so that the terminal can be driven from
  the serial console with no keyboard plugged in, which is documented in the
  board page. INPUT_KEYBOARD_BYTESTREAM is no longer needed there, since
  the terminal reads events and this configuration has no other keyboard
  consumer.

• M5Stack Cardputer. The rename only. Its driver was converted in
  Feature/kbd upperhalf #19586, so its cursor keys already arrive as keycodes.

The application documentation follows the same change: the lvglterm page
described the three sources and told the reader to pick the one matching the
hardware, the hidkbd page pointed at HIDKBD_ENCODED, which no longer
exists, and system/kbd had no page at all.

Impact

Left as it was, the unknown option would have been dropped when the
configuration was normalised and both boards would have fallen back to the
touch variant, which is the default. Neither has a touchscreen, so the
terminal would have had no input at all, and the build would have said
nothing about it.

UINPUT_KEYBOARD_BUFNUMBER is raised to 128 on the Linum. It counts events
rather than keys, so the default of eight holds four keystrokes, and a
console hands over a whole line at once. The keyboard upper half overwrites
the oldest event when the buffer is full, so a typed line arrived with its
beginning silently missing.

HIDKBD_NOGETREPORT is enabled on the Linum as well. Sampling the keyboard
over the control pipe every 40 ms loses any key pressed and released between
two samples, which on this board meant most of them.

Testing

Verified inside the CI container with this branch paired against the apps
branch, which is the state after both merge:

### Normalisation
  clean linum-stm32h753bi:lvglterm_kbda   clean sama5d4-ek:ipv6
  clean esp32s3-m5-cardputer:lvglterm     clean olimex-lpc1766stk:hidkbd
  clean sama5d4-ek:nsh                    clean nucleo-h753zi:jumbo
  clean sama5d4-ek:nxwm                   clean qemu-intel64:jumbo
  clean sim:nxdoom
### Build
  PASS linum-stm32h753bi:lvglterm_kbda    PASS olimex-lpc1766stk:hidkbd
  PASS esp32s3-m5-cardputer:lvglterm      PASS sim:nxdoom

The documentation was built the way CI builds it, with warnings treated as
errors:

$ python -m sphinx -b html -W --keep-going -q . /tmp/doc
$ echo $?
0

On the Linum, the terminal was driven on the board's LCD from a real USB
keyboard, from the serial console through the uinput bridge, and from both
at once with the USB keyboard forwarded into the same virtual keyboard.

The Cardputer was not available, so that configuration is checked by build
only.

Depends-On: apache/nuttx-apps#3687

[github-actions]

MemBrowse Memory Report

No memory changes detected for:

• arduino-mega2560
• esp32-devkitc
• hifive1-revb
• mirtoo
• qemu-armv8a
• qemu-intel64
• rx65n-rsk2mb
• s698pm-dkit
• stm32-nucleo-f103rb

[xiaoxiang781216]

@acassis please merge #19075, so we can make this pr and apache/nuttx-apps#3687 pass the ci together.
@JorgeGzm please follow ttps://github.com//pull/19075 to update the description in your pr.