When a test case successfully runs this:

    varnish v1 -start

The following macros are created:

- ${v1_addr}
- ${v1_port}
- ${v1_sock}

When v1 listens to a UNIX domain socket, those macros become useless and
we generally have to repeat the socket path wherever we need it.

From now on, varnish listen address macros for unix domain sockets match
their server counterparts:

- ${v1_addr} expands to "0.0.0.0"
- ${v1_port} expands to "0"
- ${v1_sock} expands to the socket path

It is now possible to use the following construct regardless of the
socket type:

    client c1 -connect "${v1_sock}"

In addition, the debug.listen_address command now outputs the listen
address name in addition to its endpoint. For example, in a test case
with the following command:

    varnish v1 -arg "-a :0 -a :0 -b '${bad_backend}'" -start

The output for debug.listen_address could look like this:

    a0 127.0.0.1 34567
    a0 ::1 34567
    a1 127.0.0.1 45678
    a1 ::1 45678

The resulting macros would be:

- ${v1_addr}
- ${v1_port}
- ${v1_sock}
- ${v1_a0_addr}
- ${v1_a0_port}
- ${v1_a0_sock}
- ${v1_a1_addr}
- ${v1_a1_port}
- ${v1_a1_sock}

It becomes possible to reliably listen to multiple endpoints and use
either in a test case. On a dual-stack system where we might end up
with multiple endpoints sharing the same name, only the first one is
used for a given name. In the example above all macros would expand
to IPv4 addresses.