Add PawnIO module for legacy PC speaker access

[GeniusPilot2016]

Add PcSpeaker.p to provide NeoBleeper with direct access to the legacy PC speaker on modern Windows systems.

The module programs the legacy speaker interface to:

• Generate tones
• Change tone frequency
• Start and stop continuous tones
• Check whether the PC-speaker-related hardware interface is present and responsive

The hardware check covers PIT channel 2 and System Control Port B. It does not claim to detect whether a physical speaker cone is connected or whether its output is audible.

This implementation replaces NeoBleeper's previous InpOutx64-based backend because of current and upcoming Windows compatibility issues. Microsoft has confirmed deployment of a block that prevents the inpoutx64 driver from loading on affected Windows 11 devices. Microsoft also states that this block will be included in the September 2026 Windows security updates and subsequent releases.

Source:
https://learn.microsoft.com/en-us/windows/release-health/resolved-issues-windows-11-25h2#3731msgdesc

Existing alternatives were unsuitable for this use case. BEEPx64 has driver-signing compatibility problems on current Windows versions, and HalMakeBeep did not reliably produce physical PC-speaker output during prior testing. PawnIO provides a maintained mechanism for performing the required hardware I/O without depending on InpOutx64.

The module compiled successfully and was tested with PawnIO 2.0.1 on:

• A desktop with a Gigabyte B450M H motherboard and a physical system speaker
• A Huawei MateBook D16 laptop

Tone generation, frequency changes, and start/stop operations worked without observable errors or latency on both systems.

PawnIO 2.0.1 was used because the unrestricted PawnIO 2.2.0 build rejects unofficial modules with STATUS_INVALID_PARAMETER. The unrestricted build appears to behave like the standard build, which accepts only officially signed modules.

[namazso]

Please test if HalMakeBeep works instead, it’d be much preferable as it correctly locks the mutex for the device

[GeniusPilot2016]

Please test if HalMakeBeep works instead, it’d be much preferable as it correctly locks the mutex for the device

I already tested HalMakeBeep first (via BeepXP64’s HalMakeBeep path).
On my systems it produced no audible output (including with driver signature enforcement disabled), while direct PC-speaker I/O worked reliably.

Since PawnIO.Modules is for direct hardware I/O modules, this PR intentionally uses direct access.

Please confirm which direction you want:

keep direct access (works on my tested systems), or
require HalMakeBeep/mutex-correct path even if it yields no sound on these systems.

[GeniusPilot2016]

Please test if HalMakeBeep works instead, it’d be much preferable as it correctly locks the mutex for the device

I built a side-by-side test app to compare both methods on the same system.
Result: Direct access works, while HalMakeBeep failed with: “Bir sisteme bağlı bir aygıt çalışmıyor. (0x8007001F)” — English: “A device attached to the system is not functioning. (0x8007001F)”.

So on this machine, HalMakeBeep is non-functional for audible PC-speaker output, while direct hardware access is functional.
Given PawnIO’s purpose (direct hardware I/O), this PR uses the only working path in my tests.