Socket delivery: fix race condition that might crash the manager.

When dealing with short-lived, high-rate requests, an unexpected manager death will result in cascade failure that ends up crashing the node when using the default MaxR/MaxT values for lhttpc_sup (10 restarts per sec.)

This is due to a sneaky race condition on lhttpc_manager:client_done/5. Between confirming that our pool is the current socket owner (lhttpc_sock:controlling_process/3) and actually delivering the socket back (gen_server:call/3 with 'DoneMsg') the manager might die and be restarted. If this happens, the delivery handling on lhttpc_manager will crash on 'dict:fetch/2' because this is a new manager and as such it has no idea about who the caller is.

'lhttpc_sock:controlling_process/3' now returns the resolved Pid so that we can be sure we're always calling the appropriate process (and, in case of sudden death, making sure there's no resource leakage)
Shouldn't the socket be closed on a failure to set the controlling process?