Missing real time signal prioritization

## Real Time Signals
Real time signals differ from standard signals in several different ways:

- They are available for use by applications, never explicitly by the OS.
- They are used for IPCs
- The POSIX real time extensions that added real time signals specify special APIs that are intended for real time signals (we don't make this distinction at the interface level however).
- Queuing of signal handling is optional for standard signals, it is required for real time signals.

But the most important difference and the one that NuttX does not address is:

- Real time signals are prioritized.

## Signal Prioritization

This is important for good real time performance of real time signals as an IPC.

SIGRTMIN is the number of the highest priority real time signal; Higher numbered signals have lower priority. Standard signals are unprioritized and, if queued, should be processed FIFO. Nuttx does queue signal handling, but all signals are unprioritized and handled FIFO.

POSIX does not specify the relative priority of standard signals and real time signals. Linux handles that in this way: All signals are prioritized. That is not quite consistent with POSIX and creates some odd prioritization (like CONFIG_SIG_USR1/2 are high priority than SIGTERM or SIGSTOP). It also means that all of the standard signals are higher in priority and any of the real time signals.

Adopting the Linux behavior is easy: The single FIFO queue becomes prioritized (but FIFO for pending signal handling of the same signal). Following POSIX is not much more difficult: We would need two queues: An unprioritized FIFO queue for the standard signals and a prioritized queue for the real time signals.

## Nested Signal Handling
Currently, NuttX does not supported nested signal handlers. Here is where one-at-a-time signal handling is enforced for ARMv7M: https://github.com/apache/nuttx/blob/master/arch/arm/src/armv7-m/arm_schedulesigaction.c#L88

/* Refuse to handle nested signal actions */

if (tcb->xcp.sigdeliver == NULL)
{

Interrupting one signal handler to process another implies some priority handling of signals. Why would you interrupt one handler to run another versus letting the current handler run to completion first.

If prioritized signal handling is implemented, then we should also reconsider this. It might not be a bad thing to permit a higher priority signal handler to interrupt a lower priority signal handler.