p.haul: do not use getsockname() as a hash_name, v4

Currently xem_rpc is not proxy-resistant.
It means that if there is a proxy somewhere in
between client and server, p.haul will fail,
because getsockname() on client != getpeername()
on server.

v2, Pavel suggested to solve it like this:

1. On main rpc socket after init_rpc() the server
   reports back the name by which it sees the client
   socket.

2. After calling connect() on data socket the client
   should mix the name from step 1 to the data socket
   name to distinguish his data socket from those
   created by other clients.

v3, use rpc to transfer socket name
v4, use init option in _make_sk
p.haul: use ssh tunneling and controll it with ssh* cmdline opts

Currently we have such security holes:

1) All p.haul traffic goes without any encryption, which is
not safe at all, cosidering that attacker can easily peek memory pages
of migrating process. Lets solve that by using ssh tunnel which allows
us to easily encrypt and compress traffic.
Compressing is useful only when connection is very slow, but will only
slow down things on fast networks.
Using ssh tunnel also allows us to solve keys\certificates management
problem in a very common way that is familiar to any system administrator.

2) p.haul-service binds to 0.0.0.0 and is accesible from the outside
for anyone who is trying to connect to it. So attacket can easily connect
to p.haul-service and migrate some malicious process to the server.
Lets fix that by binding p.haul-service to 127.0.0.1 so it is accessible
only from its localhost.

So, basically, we perform following actions when migrating process
from src to dest:
1. (user@dest) Start p.haul-service on localhost:12345
2. (user@src)  Create ssh tunnel:
	ssh -NC 54321:localhost:12345 remote_ip
3. (user@src)  Connect p.haul to localhost:54321 and migrate

Conflicts:
	xem_rpc.py