parasite: Switch parasite to daemon mode (v2)

Parasite daemon mode it quite tricky. One may consider
it as consisting of two parts

 - daemon mode for thread leader
 - daemon mode for regular threads

Thread leader daemon
--------------------

Once thread leader parasite code switched initialized,
it starts spinning on socket listening for commands
to handle.

If the command destination is the thread leader itself it
handles it and replies back the ack to the caller (iow
the main crtools code).

If the recepient is not thread leader but one of threads,
then thread leader wakes up the thread by futex and makes
it to handle the command waiting on futex for result. Once
result obtained, the ack is being sending back to caller.

Thread daemon
-------------

On initialization thread daemon starts waiting a command on futex.
The futex is triggered by thread leader daemon when command received.
Once command is received and handled, the result is reported back to
the thread leader daemon, which in turn send ack message.

Both thread-leader and regular threads require own stack to operate
on since they all are present in memory simultaneously. Thus we use
call_daemon_thread() helper which takes care of providing stack
to the callee.

TODO:

 - ARM requires own wrappers on damonize/trap low-level code,
   at moment x86-64 is only covered

v2: remove PARASITE_CMD_DAEMONIZED and s->ack
    parasite: use a propper command for getting ack

Fixed-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
parasite: restore thread registers

crtools dump should not be destructive.

We suppose that item->threads[0] is a thread leader.
dump: update task registers if a signal is started handling

When we try to execute a parasite code, a signal can be started
handling, so we need to update a task registers, which will be saved in
a core file.
dump: save registers when the task is already infected

Otherwise a task can start to handle a signal and registers can be
changed.
dump: return signal mask from parasite on initialization

and check that signals are blocked for each thread separately
restore: use a concrete object for constructing sigframe

struct thread_restore_args contains many pointers on different objects,
only a few of them are really required.
restore: add a function for constructing sigframe
restore: split restore_gpregs on two parts

The first one fills sigframe and the second one restores another
registers.
restore: construct sigframe in crtools

Before this patch sigframes were constructed in restorer. We are going
to construct sigframes for parasites. Both parasite and restorer should
be as thing as posible.
dump: fill sigblock mask immediately after getting it

It will be used for constructing sigframe for parasite threads
dump: reseve space and construc sigframes for parasites
parasite: transfer a pointer on sigframe to parasite
parasite: restore parasite state via rt_sigreturn

This patch reduces a window, when a crtools can kill a dumped process,
because if a parasite in a deamon mode can restore the state of the
process, if crtools detached unexpectedly.

All threads are synchronized on the exit point from sys_rt_sigreturn,
for that crtools traces all syscalls.
parasite: remove the hash table for tid_state-s

Use the same indexes which used for item->threads
parasite: don't store sig_blocked in a parasite