1) The signal handler is executed the next time the target process returns from kernel mode to user mode.
This occurs either when the process is scheduled to run again after a hardware interrupt (and it wasn't already running in kernel mode), or when the process returns from a system call (on some architectures, these are the same thing).
In normal operation, when leaving kernel mode, your process will simply return to the next instruction after the point where it originally left user mode.
However if a signal is pending for your process, the kernel will re-write your processes context such that the return to user mode will instead go to the first instruction of your signal handler and your stack will have been modified to look like you had made a "special" subroutine call to the signal handler at the point where you originally left user mode (the return from this "special" subroutine call involves making a system call to restore the original state).
For details read this, this and this.
So the 'target' process may receive its execution token from the Scheduler any number of times before the signal handler is finally executed (if it happens to stay in kernel mode for some reason).
2) No - the signal handler will only ever execute in the user mode context of your process.
3) The aren't really any execution priorities in a time-shared system such as Linux, unless you count the nice value of a process, so you can't sweep away something that isn't there.
Things are complicated by threads and so-called real time scheduling policies, so the comments above are only valid for single-threaded processes running with non-real-time scheduling policies (the only sort of process that existed in the good old days :-).