pass_fd:  Work around Mac OS X fd leak

Prior to this change, running a Freemount client on Mac OS X 10.4.11 and
connecting to another machine with utcp would intermittently fail in the
second recv_fd_t() call in unet-connect, leaving the server blocked in a
read() call.  Since the second fd send succeeds, but the recv fails, and
the server never gets a FIN (suggesting the fd is never closed), I'm led
to conclude that the socket file descriptor in flight is getting lost in
the aether.  The workaround ensures that, on Mac OS X, a file descriptor
in flight is received before the send_fd() call that sent it returns, so
a second send_fd() call won't overlap the first file descriptor's flight
time.  Specifically, (a) send_fd() concludes by reading a data byte from
the control channel, which blocks until (b) recv_fd() writes a data byte
to the control channel after receipt of the file descriptor in flight is
complete.

This issue hasn't been observed on other platforms.