Reject requests that break the RFC 9112 request-target and Host rules

[digitalresistor]

Fixes the remaining request parsing issues reported by @TUO-Wu: #462 (in part),
#463 and #467. Each is a separate commit with its own tests and changelog entry.

Require a valid Host header field on HTTP/1.1 requests

Closes #462.

RFC 9112 section 3.2 requires a 400 (Bad Request) response to any HTTP/1.1
request that lacks a Host header field, or that carries one with an invalid
field value. #484 rejected duplicate Host header fields, which is the same
sentence of the same section, but a request with no Host header field at all was
still served, and the value was never looked at:

$ printf 'POST / HTTP/1.1\r\nContent-Length: 0\r\n\r\n' | nc 127.0.0.1 8080
HTTP/1.1 200 OK

The value is now checked against the uri-host [ ":" port ] grammar of RFC 3986
section 3.2.2, whatever the version of the request, so that something which
isn't a host can't reach the WSGI application and get interpreted differently
there than it was here.

Use the absolute-form request-target authority as the Host

Closes #467.

RFC 9112 section 3.2.2 requires that an origin server receiving a request with
an absolute-form request-target ignore the Host header field and use the host
information from the request-target instead. Waitress did the opposite: it
parsed the authority into proxy_netloc and then never looked at it again, so

$ printf 'GET http://evil.com/page HTTP/1.1\r\nHost: victim.com\r\n\r\n' | nc 127.0.0.1 8080

reached the application as victim.com. Anything in front of Waitress that
follows the RFC would have routed that request to evil.com, and a disagreement
of that shape is the basis of a host confusion attack.

The authority now replaces the Host header field value and is validated the same
way. That rejects a userinfo subcomponent, since @ may not appear in a
uri-host, and RFC 9110 section 4.2.1 separately requires that an http URI with
an empty host be rejected as invalid. A request-target starting with // still
parses as a path rather than an authority, preserving the behaviour asked for in
#260.

Validate the authority-form request-target of a CONNECT

Closes #463.

RFC 9112 section 3.2.3 requires that the request-target of a CONNECT be an
authority-form, and that a server reject a CONNECT targeting an empty or invalid
port number.

This does not reject the method. Waitress still leaves it to the WSGI
application to decide what to do with a CONNECT, up to and including
implementing a proxy with it. What it validates is the shape of the
request-target, so that an application splitting a host from a port is working
with something well formed rather than having to re-derive that itself.

request-target	before	after
example.com:443	pass-through	pass-through
[::1]:443	pass-through	pass-through
example.com	pass-through	400, no port
example.com:0	pass-through	400, invalid port
example.com:65536	pass-through	400, invalid port

Where it passes through, the environ is unchanged from main field for field —
same REQUEST_URI, PATH_INFO and HTTP_HOST.

The validation has to run before split_uri() sees the request-target, because
urlsplit() reads example.com:443 as the scheme example.com followed by the
path 443. For the same reason a CONNECT is excluded from the absolute-form
handling above — an authority-form is not an absolute-form, and without the
exclusion CONNECT example.com:443 would look like one with an empty authority.

Backward incompatibilities

These are all cases that used to be answered with a 200, so they are called out
in CHANGES.txt:

• An HTTP/1.1 request without a Host header field is now a 400.
• A Host header field whose value is not a uri-host [ ":" port ] is now a 400,
  at any HTTP version. In particular an internationalised domain name has to be
  punycoded by the client, as it always should have been.
• An absolute-form request-target now determines HTTP_HOST, and one with an
  empty authority or a userinfo subcomponent is a 400.
• A CONNECT whose request-target is not a valid authority-form is now a 400.

Notes

• The changelog was missing entries for the duplicate header field fixes that
  landed in Reject duplicate Host headers per RFC 9112 #484 and Reject requests with duplicate Content-Type #488, so the first commit backfills those.
• A fair number of existing tests sent HTTP/1.1 requests without a Host header
  field and needed one added; that churn is contained in the Issues in Parsing HTTP Request "Host" Header #462 commit.
• Ignore Host header in favor of absolute-form request-target authority #496 is an open PR against Incorrect Handling of Absolute-Form Request-Target Authority #467. This implements it independently.
• Full suite passes at each commit individually, and parser.py and
  rfc7230.py are both at 100% coverage.