Add signal handling for SIGTERM in addition to SIGINT

[dfangl]

Motivation

This PR addresses #1258 by adding a SIGTERM handler in addition to a SIGINT handler to pass the control back to the python process, should the signal be cought.

Changes

• Add parameter of the signal value to the interruptPy method, to be able to pass the right signal to python
• Install SIGTERM handler

Discussion

We might want to have the sigterm handling behind a separate flag, as being discussed in #1258. Happy to do this, should it be preferred.

[Thrameos]

Looking at the PR I don't think a different flag is needed. But will review further later.

[Thrameos]

PyErr_SetInterruptEx did not appear until 3.10. You will need to add version controls around the statement to get it to pass all checks. Also a unit test would be a good idea, or the code may get broken in some uncontrolled way in the future.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 86.91%. Comparing base (fa54bca) to head (3a69715).

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1259      +/-   ##
==========================================
+ Coverage   86.87%   86.91%   +0.04%     
==========================================
  Files         113      113              
  Lines       10336    10336              
  Branches     4065     4065              
==========================================
+ Hits         8979     8984       +5     
+ Misses        761      757       -4     
+ Partials      596      595       -1     

Files with missing lines	Coverage Δ
native/common/jp_context.cpp	75.55% <ø> (+1.66%)	⬆️

... and 1 file with indirect coverage changes

[Thrameos]

Looks like there is still a windows issue. Once that is complete I can review and merge.

[dfangl]

I skipped the tests on windows for now. SIGTERM is not a thing on Windows, and it seems like the SIGINT handling does not work either, the process just seems to crash.

"Signal" handling on Windows does not make a lot of sense anyway, but it might make sense to fix the CTRL-C behavior in windows at some point (assuming it actually does not work as the tests suggest, and not just the test setup is wrong).

I don't have a Windows setup right now, but should skipping not be acceptable, I will set one up.