hostmot2: initialize new tram region to zero

Failing to do this caused an uninitialized memory read at startup in
hm2_watchdog_force_write < hm2_force_write < hm2_register, because
hm2->watchdog.status_reg is now in tram memory but at this point there
has been no tram read.

This would sometimes cause
    hm2/hm2_7i80.0: Watchdog has bit!
at startup, far before the configured watchdog timeout.  This change
also eliminates a valgrind diagnostic at startup, another facet of
the same problem:
 Syscall param socketcall.sendto(msg) points to uninitialised byte(s)
   at 0x5BF764C: send (send.c:32)
   by 0x6BBECBE: hm2_eth_write (hm2_eth.c:335)
   by 0x699E279: hm2_force_write (hostmot2.c:1633)
   by 0x699F6C8: hm2_register (hostmot2.c:1436)
(hostmot2:1633 is the call to hm2_watchdog_force_write)
hm2-eth: system() is harmful to realtime priority

Both PCW and I saw that after the addition of calls to system(), there
were frequently 'realtime delays' logged at startup, particularly when
running with a 2kHz servo thread.  It does not appear to be the fault
of the command itself being executed, because running 'iptables -L fnord'
in another window while realtime is running does not cause realtime delays.

On Linux, based on looking at strace output, it appears that system() is
implemented in terms of clone(fork)+exec, while posix_spawn() is
implemented in terms of vfork+exec.  It's not clear why this difference
preserves realtime performance (at least for me), but if it works we'll
take it.