Fix esp32 wait-timing race, rename wc_api.lib, keyboard: Enter-to-advance

esp32.c: two-phase esp_wait_busy() so a stale non-BUSY status right after
esp_cmd() isn't mistaken for completion (fixed a real TRACK_PLAY/0x88 race
on heavier XM files); added single-phase esp_wait_not_busy() for
esp_send_dma()'s per-chunk wait, which never actually sets BUSY and was
timing out on every chunk under the two-phase version.

vgm_wc_api.lib renamed to wc_api.lib (build.bat updated to match).

Keyboard: tried replacing wc_key_esc/pgup/pgdn/space with a raw PS/2-FIFO
reader (matching how VGMPLAY.WMF's own player reads keys) so Enter could
also advance to the next file. Reverted after two confirmed hardware
regressions (esp32 transfers failing with ESP_ERR_INV_XM, and the keyboard
going unresponsive once WC's own PS/2 scanning was disabled to stop it
competing with the raw reads) - VGMPLAY's approach relies on a full custom
interrupt handler xmplay has no equivalent need for. Back to the simple
wc_key_*() wrappers, plus wc_key_enter() so Enter now advances too, and
wc_key_wait_release() (called after wc_gedpl()) to debounce the Enter/F3
that launched the plugin itself.

Also: About window now centers dynamically for all three WC text modes
(90x36/80x25/80x30) instead of a fixed position, and matches the main
window's color scheme.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

obj/out.lk

@@ -3,7 +3,7 @@
 -b _CODE = 0x8003
 -b _DATA = 0xa800
 -k E:\SDCC\4.6.0\bin\..\lib\z80
--l vgm_wc_api.lib
+-l wc_api.lib
 -l z80
 obj/out.rel
 obj/crt0.rel