Change the signal used by security-manager prepare_app implementation

Change the signal used by security-manager prepare_app implementation

SIGSETXID was used previously to mimic the exact behaviour of glibc.

However, in testing on VD side using SIGSETXID can cause interference
with regular glibc usage, which also leads to abort().

To give more details: if threads are so delayed that their signal handling
is done ie. > 2 seconds after the sending was done, the signal arrives
in the thread when security-manager already did change the signal handler
back to original glibc. Then, glibc, checks whether it sent the signal,
it recognizes it didn't, and aborts/quits.

Changing signal number will not cause glibc to abort/fail, and if execution
gets back to security-manager main thread, IT will fail, printing
all necessary information about threads for debugging, before calling abort().

Changed signal number to SIGRTMIN+2, as advised.

Change-Id: I9b755504898daee71997ee35023c3d647e332b84