Fix stack overflow reporting with multiple PALs (#107264)

* Fix stack overflow reporting with multiple PALs

A recently reported issue in the stack overflow test running with
superpmi collect has revealed that there is a problem when multiple
shared libraries using coreclr PAL are loaded into the process.
Each such library registers signal handlers, including the SIGSEGV
one. The unexpected thing in the SIGSEGV handler in this scenario
is the fact that the GetCurrentPalThread() returns NULL in the
non-coreclr shared libraries in case the library didn't invoke
any function that would create the thread object.
That leads to the handler just writing "Stack overflow." to
the console and then calling PROCAbort(). This abort causes the process
to be torn down without reporting the stack overflow with full stack
trace by the coreclr.

This change fixes it by calling the previous registered handler instead
aborting in this case. That gives the coreclr SIGSEGV handler a chance to
do the reporting as expected.

* Reflect PR feedback - move comment

Author: janvorli

src/coreclr/pal/src/exception/signal.cpp

@@ -646,15 +646,14 @@ static void sigsegv_handler(int code, siginfo_t *siginfo, void *context)
                 {
                     PROCAbort(SIGSEGV, siginfo);
                 }
-
-                // The current executable (shared library) doesn't have hardware exception handler installed or opted to not to 
-                // handle it. So this handler will invoke the previously installed handler at the end of this function.
             }
             else
             {
                 (void)!write(STDERR_FILENO, StackOverflowMessage, sizeof(StackOverflowMessage) - 1);
-                PROCAbort(SIGSEGV, siginfo);
             }
+
+            // The current executable (shared library) doesn't have hardware exception handler installed or opted to not to
+            // handle it. So this handler will invoke the previously installed handler at the end of this function.
         }
         else
         {