Drop pseudo-automatic support for multihomed backends and require

Drop pseudo-automatic support for multihomed backends and require
clear expression of intent in VCL.

We now fail backend hostnames that resolve to multiple IPv4 or multiple
IPv6 addresses, in other words, you cannot use "cnn.com" as a backend
hostname specification without the compiler yelling at you:

    % ./varnishd -d -d -b cnn.com -a :8080
    Backend host "cnn.com": resolves to multiple IPv4 addresses.
    Only one address is allowed.
    Please specify which exact address you want to use, we found these:
	    64.236.16.20
	    64.236.16.52
	    64.236.24.12
	    64.236.29.120
    [...]
    VCL compilation failed

However, you _can_ use a hostname that resolves to both an IPv4 and
an IPv6 address, and the new paramter "prefer_ipv6" will determine
which one we try first in such cases.

The other part of this change is that we now do the DNS lookup at
VCL compiletime, and only then.

If your backend's DNS record (or /etc/hosts entry) changes IP#, you
must reload your VCL code to notify varnish.

Finer technical points:

We build a bytestring representation of the sockaddr's in VCC and
include them in the concept of backend identity, for an existing
backend (+ connections) to be reused for a new VCL the backend must
now be defined exactly the same way AND have the same resolved
IPv4/IPv6 addresses.

Since we never muck about with the address in the backend struct
anymore, it's static for the life of the struct backend instance,
we can simplify and eliminate the locking dance around our connection
attempts.

Also eliminate the struct vrt_backend inclusion in struct backend,
and instead make the relevat fields full-blown members of struct
backend.  This eliminates a number of TRUST_ME() calls.

This is the companion commit to #2934 which prepared the VCL compiler.

git-svn-id: svn+ssh://projects.linpro.no/svn/varnish/trunk@2936 d4fa192b-c00b-0410-8231-f00ffab90ce4