server: don't panic when a finished compile has neither code nor signal

[jetm]

Part of #2775 (splitting the OpenEmbedded/Yocto sccache-dist work into focused
PRs; replaces the closed #2750).

Problem

get_signal did 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: an ExitStatus reconstructed for a distributed compile (or
an abnormal wait status such as WIFSTOPPED) can report neither a code nor a
signal. When that happened the expect() panicked the compile task, which the
server surfaced as a misleading "Failed to bind socket" and, under load,
repeatedly fell back to local compilation. Found under a Yocto/BitBake host-mode
distributed build.

Approach

Return Option<i32> from get_signal and assign it straight into res.signal,
so a compile that reports neither code nor signal leaves res.signal unset
instead of crashing the in-flight task. The Windows arm returns None rather
than panicking; ExitStatus::code() is always Some there, so the signal branch
is never reached anyway.

Test

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