Implement "null vmchannel" - no vmchannel needed!

Implement "null vmchannel" - no vmchannel needed!

This commit removes the requirement for vmchannel, although retaining
support for it.

In this configuration, known as "null vmchannel", the library
listens on a random loopback port.  It passes the number of this
port to the appliance (guestfs_vmchannel=tcp:10.0.2.2:12345), and
the daemon then connects back.  The library, instead of connecting,
listens and accepts the connection during guestfs_launch.

QEMU SLIRP (user mode networking) is still required to make this
work: SLIRP forwards the TCP connection transparently (instead of
explicitly as with guestfwd) to 127.0.0.1:<port>

There is a window in which any other local process on the machine
could see the port number in the qemu command line and try to
connect to it.  This would be a devastating security hole, because
any local process could pretend to be the daemon and feed back
malicious replies to our remote procedure calls.  To prevent this,
we check the UID of the other side of the TCP connection.  If
the UID is different from the library's EUID, then we reject the
connection.  To do this we have to parse /proc/net/tcp.  (On Solaris
we could use getsockopt (SO_PEERCRED), but this doesn't work on
Linux TCP sockets).

Other vmchannel(s) are still supported.  This is important, because
we can't in general be sure the qemu will always support SLIRP.
In particular, in recent versions of qemu it is possible to compile
out SLIRP.