Fix two related bugs with -B and IPv4 addresses.

If specifying -B with an IPv4 literal address or with an FQDN that
resolved to an IPv4 address, but we had not explicitly specified an
address family with -4, we failed to set up the socket correctly
because we assumed binding to an IPv6 address, and instead (after some
error spewage) wound up binding to wildcard address.

The fix in this commit has multiple parts:  First, if the address
family hasn't been explictly specified, don't force AF_INET6 in the
hints to getaddrinfo(3).  AF_UNSPEC should generate the correct
(according to RFC 6724) behavior.

Second, iperf_reset_test() should not discard members that were passed
from command-line parameters, because that alters the behavior of the
iperf3 when it tries to recreate the listening socket.  In the failure
situation described in this issue (and possibly other as well), the
value of -B gets discarded, so on subsequent attempts to set up the
listening socket it just binds to the wildcard address.

While here, fix on-line help related to the -B option to match
reality.

Note that we're not completely in compliance with RFC 6724, which
states that we should actually try all of the addresses in returned by
getaddrinfo(3), rather than just the first one.

Fixes Issue #193.

(cherry picked from commit 5b760eef47f9d0535a2e4ef0cbaee66a7735e1c0)
Signed-off-by: Bruce A. Mah <bmah@es.net>

Conflicts:
	src/locale.c