runtime: don't treat SIGURG as a bad signal
    
    It's possible for the scheduler to try to preempt a goroutine running
    on a thread created by C code just as the goroutine returns from Go code
    to C code. If that happens, the goroutine will have a nil g,
    which would normally cause us to enter the badsignal code.
    The badsignal code will allocate an M, reset the signal handler,
    and raise the signal. This is all wasted work for SIGURG,
    as the default behavior is for the kernel to ignore the signal.
    It also means that there is a period of time when preemption requests
    are ignored, because the signal handler is reset to the default.
    And, finally, it triggers a bug on 386 OpenBSD 6.2. So stop doing it.
    No test because there is no real change in behavior (other than on OpenBSD),
    the new code is just more efficient
    
    Fixes #36996
    
    Change-Id: I8c1cb9bc09f5ef890cab567924417e2423fc71f6
    Reviewed-on: https://go-review.googlesource.com/c/go/+/217617
    Reviewed-by: Austin Clements <austin@google.com>