…19432)

Replaces pr #19412

### Summary of the issue:
With the switch to 64 bit, NVDA no longer supports sapi4, or 32 bit
specific sapi5 synthesizers. NVDA should somehow continue to support
these synthesizers.

### Description of user facing changes:
NvDA continues to support sapi4 and 32 bit specific Sapi5 synthesizers.

### Description of developer facing changes:

### Description of development approach:
* Compile nvdaHelperLocal for all archetectures, rather than just for
NVDA's core archetecture (x64). NVDA's 32 bit synthDriver host runtime
needs nvdaHelperLocal for WASAPI.
* Move the wasapi function definitions for nvdaHelperLocal.dll into
their own 'wasapi' Python module, so that they can be imported separate
to NvDAHelper. NVDA's 32 bit synthDriver host runtime uses WASAPI
directly.
* Compile sonic independently of eSpeak and for all archetectures (not
just x64), as it is needed by sapi5 when running in NVDA's 32 bit
synthDriver host runtime. The x86 sonic dll will be placed in
source/synthDrivers32.
* winBindings.kernel32: add definition for GetCurrentProcessId. Used in
logging for NVDA's 32 bit synthDriver host runtime.
* Add a jobObject module, which contains a Job class which wraps a win32
Job object, which allows automatically killing any process associated
with it. This is sued to ensure that any process started for the 32 bit
synthDriver host runtime is killed off if NvDA exits.
* Add a _bridge package, which provides a client and runtime for the 32
bit synthDriver host. The client is code that runs in NVDA, and the
runtime is code that runs in its own 32 bit child process. Communication
between NvDA and the child process is via RPYC over the child processs's
standard pipe handles. This _bridge package can be later extended with
more clients and runtimes as we start to implement a full ART.
 
* Add 32 bit sapi4 and sapi5 synthDrivers which use the
synthDriverHost32 runtime.

### Testing strategy:
Manually tested running NvDA with both 32 bit sapi4 (Truevoice and MS
Mike Mary Sam) and 32 bit sapi5 (Windows built-in David, eSpeak bridge,
Mikropuhe). Ran with NvDA launcher, installed normal user, and on secure
desktop (UAC and logon screen).

### Known issues with pull request:
* This PR only supports sapi4 and 32 bit sapi5 quite specifically. It is
not a generalized 32 bit shim for add-ons. To do this, we would need to
include the security features from pr #19412 and greatly increase the
size of the runtime, and add many more proxies and services. In other
words, complete the secure ART project ;). To have something ready for
2026.1, we have decided to limit this to sapi4 and 32 bit sapi5.

…playing directly. (#19577)

### Summary of the issue:
the 32 bit sapi synthDrivers added in pr #19432 currently play audio
directly. Although this provides good performance and works in most
scenarios, it does not allow supporting audio ducking (as the host
process does not have permission to duck audio, and if NvDA did
ititself, it would inappropriately duck the wrong thing). Also, as we
start moving to a secure add-on runtime, 3rd party synthDrivers (at
least on secure desktops) will most likely be run in an appContainer,
which unfortunately deos not allow the host process to access tha audio
device directly. thus, to work around both of these issues, the 32 bit
sapi synthDrivers should send the audio to NvDA for playback.

### Description of development approach:
Take more code from pr #19412, specifically the WavePlayer service and
proxy, the pipe creation code, and raiiUtils.
NvDA exposes a WavePlayer service, allowing an external process such as
the 32 bit sapi synthDriver processes to send audio.
 
### Testing strategy:
General smoke testing of sapi4 and 32 bit sapi5 synthDrivers.

### Known issues with pull request:
* the Mikropuhe sapi5 voices sound a bit scratchy / jittery like there
are buffer underruns. I may require some assistance in improving the
stability / performance here. Sapi4 truevoice seems to work fine, sapi5
espeak and in-built windows sapi5 voices also seem to be fine.