#2075 saveMacroSpace() writes uninitialised bytes to the macrospace file

[Moritz Hoffmann]

Running the test suite under valgrind memcheck reports uninitialised heap bytes being passed to
write() from the macro space save path:

Syscall param write(buf) points to uninitialised byte(s)
at write (write.c:26)
by SysFile::writeData(char const, unsigned long) common/platform/unix/SysFile.cpp:493
by SysFile::flush() common/platform/unix/SysFile.cpp:329
by SysFile::write(char const, unsigned long, unsigned long&) SysFile.cpp:575
by MacroSpaceFile::write(void const*, unsigned long) rexxapi/client/LocalMacroSpaceManager.cpp:236
by LocalMacroSpaceManager::saveMacroSpace(...) rexxapi/client/LocalMacroSpaceManager.cpp:480
by RexxSaveMacroSpace rexxapi/client/MacroSpaceApi.cpp:154
by TestSaveMacroSpace_impl(...) orxclassic.cpp:381

Three distinct write() contexts and three socketcall.sendto() contexts show the same pattern
(265400 errors from 48 contexts total, mostly uninitialised-value reports).

Consequences: macrospace files contain non-deterministic padding bytes, so byte-identical inputs
produce differing files, and unrelated heap contents are persisted to disk (and, on the sendto()
paths, onto a socket).

Because SysFile buffers, valgrind attributes the report to the flushing write rather than to the
call that introduced the uninitialised bytes. The most likely source is structure padding in the
records written via MacroSpaceFile::writeMacroDescriptor() / the file header, rather than the
macro image data itself — I have not pinned down the exact field.

Suggested fix: zero-initialise the descriptor/header structures before populating them (e.g.
memset or value-initialisation), rather than relying on field-by-field assignment which leaves
padding indeterminate.

Platform: Linux x86_64, gcc, valgrind-3.27.1, current trunk.