Don't report success when the build is killed by a signal

[munzzyy]

ufbt_cli() turns the os.system() status into an exit code by shifting off the low byte:

retcode = os.system(commandline)
if platform.system() != "Windows":
    # low byte is signal number, high byte is exit code
    retcode = retcode >> 8
return retcode

The comment is right that the low byte holds the signal number, but that's exactly the case the shift breaks. When the child is killed by a signal the high byte is 0, so >> 8 gives 0 and ufbt exits reporting success for a build that never finished.

normal success                       raw=  0   current=  0   fixed=  0
normal failure (exit 1)              raw=256   current=  1   fixed=  1
killed by SIGINT (Ctrl-C mid-build)  raw=  2   current=  0   fixed=130
killed by SIGSEGV (toolchain crash)  raw=139   current=  0   fixed=139

Ctrl-C during a build is the easy way to hit it. A toolchain segfault or an OOM kill does the same thing. Anything gating on $? then carries on as if the .fap built, whether that's a wrapper script, a Makefile or CI.

os.WIFSIGNALED() and os.WEXITSTATUS() are the documented way to read that status. Using 128 + signal matches what a shell reports, so Ctrl-C shows up as the familiar 130. Normal exits come out unchanged, since WEXITSTATUS returns exactly what the old shift did.

Windows is untouched — that branch already skips the shift, and these macros are POSIX-only.