Don't panic in get_signal when a finished compile has neither code nor signal

[jetm]

Problem

get_signal does status.signal().expect("must have signal"), assuming the Unix
invariant that an ExitStatus with no exit code was terminated by a signal. That
does not always hold. When the server reconstructs an ExitStatus for a
distributed compile whose compiler died abnormally, the status can carry neither
an exit code nor a terminating signal, and the expect() panics the compile task.

I hit this with sccache-dist: when the build server's packaged toolchain fails
to start a compile (e.g. gcc: error while loading shared libraries: libm.so.6),
the synthesized status has neither a code nor a signal. The panic crashes the
in-flight task, which the server then surfaces as a misleading
Failed to bind socket: ... panicked with message "must have signal", and under
load it recurs on every such compile.

Fix

Return Option<i32> from get_signal and assign it straight into res.signal,
so a compile that reports neither a code nor a signal leaves res.signal unset
instead of panicking.

This matches the contract the client already implements: handle_compile_finished
in commands.rs handles the case where both retcode and signal are None by
printing Missing compiler exit status! and returning -3. The server simply
never reached that path because it panicked first.

The Windows arm returns None rather than panic!; ExitStatus::code() is always
Some there, so the signal branch is unreachable anyway.

Test

Added a unit test covering a real terminating signal (SIGKILL) and the
neither-code-nor-signal case (WIFSTOPPED via ExitStatusExt::from_raw), which
previously panicked.

With the fix, the same sccache-dist scenario now reports Missing compiler exit status! and falls back to local compilation instead of crashing the server.

[jetm]

Superseded by #2750, which combines this with the rest of the OpenEmbedded/Yocto distributed-compile fixes into a single series. Closing in favor of that PR.