Do not lock while calling signal handles

[BCSharp]

This PR removes a lock hold that used to be held during the execution of a custom signal handler. For two main reasons:

1. CPython does not synchronize the execution of custom handlers (although it always runs them on the main thread) — if a signal comes during the execution of a custom signal handler function, the function will be interrupted and re-entered.
2. In theory holding a lock during the callback could create a deadlock — in IronPython any thread can set a signal handler (in CPython — only the main thread), so if the callback waits on a thread that tries to change signal registrations, it will cause a deadlock.

Point 1 would technically be a breaking change since the callback has to be now thread-safe (re-entrant, like in CPython), except that the only signal currently supported is SIGINT and it will always result in ThreadAbortException, even when handled by the custom handler. This is deadly on POSIX since thread abort is unsupported, so likely nobody tries to handle it in this way.

There are some other smaller changes in this PR as well, mostly editorial.

[slozier]

Console.WriteLine is a bit weird, but I guess that was there before... so LGTM!

[BCSharp]

Yes, it is weird and yes, it was like that before. It seems that CPython prints it on stderr and then terminates. I will revisit it later once the signals on POSIX are working.