Parse bracketed IPv6 authorities

[AYastrebov]

Problem

A bracketed IPv6 authority is parsed as a hostname. On master:

NetLocation::from_str("[2001:db8::1]:443", None)
// => Ok((Hostname("[2001:db8::1]"), 443))

Address::from classifies by scanning bytes, and a leading [ is neither a
digit, a hex letter, : nor ., so it clears the IPv4 and IPv6 flags and the
string falls through to the hostname branch. It then goes to the resolver,
which answers "Name or service not known". [host]:port is the form RFC 3986
defines and the form HTTP clients send, so an IPv6 outbound written the normal
way is unreachable, and the error says nothing about why.

The HTTP inbound has the same problem for a different reason: it splits the
CONNECT authority on the first :, which for an IPv6 literal sits inside the
address. CONNECT [2001:db8::1]:443 is refused, and so is a forward URL like
GET http://[2001:db8::1]/.

Fix

address: parse the bracketed IPv6 form strips the brackets in Address::from
and parses the interior as an Ipv6Addr. Brackets mean an IP literal and
nothing else, so a bracketed string that is not an IPv6 address is now an error
rather than a name to look up: [example.com], [1.2.3.4] and an unterminated
[::1 are all refused. NetLocation::from_str needed no change, since its
rfind(':') already lands on the port separator once the address itself parses.

http: accept a bracketed IPv6 authority parses the CONNECT target and the
forward-URL authority through NetLocation instead of splitting on the first
colon.

Tests

Five in address.rs: the bracketed form (compressed, full eight-group and
IPv4-mapped), the refusals above, a bracketed authority with a port, a
bracketed port range, and unbracketed addresses still parsing as they did. Two
in http_handler.rs drive a request through the handler, one for CONNECT and
one for a forward URL.

cargo test passes (783), cargo fmt --check is clean, and cargo clippy
reports nothing new.