Fix forced signal delivery

[Sangho Lee (sangho2)]

This PR fixes forced delivery of a signal. handle_exception_request covers SIGFPE, SIGTRAP, and SIGILL, but force_signal_with_info asserts the signal is SIGKILL or SIGSEGV. A guest's handlers for those three signals never run.

[github-actions]

🤖 SemverChecks 🤖 No breaking API changes detected

Note: this does not mean API is unchanged, or even that there are no breaking changes; simply, none of the detections triggered.

[Weiteng Chen (CvvT)]

LGTM, thanks!

[Weidong Cui (wdcui)]

I didn't find any issue, but the agent reported the following issue:

This PR makes SIGFPE/SIGILL delivery reachable, but  siginfo_exception()  still emits  SI_KERNEL  with address  0 . Linux handlers expect  FPE_INTDIV  or  ILL_ILLOPN  and the faulting RIP. The fix must also bypass  RLIMIT_SIGPENDING  explicitly for forced signals; simply changing  si_code  would allow these signals to be dropped. SIGTRAP can retain  SI_KERNEL .

[Sangho Lee (sangho2)]

I didn't find any issue, but the agent reported the following issue:

This PR makes SIGFPE/SIGILL delivery reachable, but  siginfo_exception()  still emits  SI_KERNEL  with address  0 . Linux handlers expect  FPE_INTDIV  or  ILL_ILLOPN  and the faulting RIP. The fix must also bypass  RLIMIT_SIGPENDING  explicitly for forced signals; simply changing  si_code  would allow these signals to be dropped. SIGTRAP can retain  SI_KERNEL .

The review makes sense, which would bump up this one-line change though. Let me figure out minimal change.