These are based on my implementation in https://bugs.webkit.org/show_bug.cgi?id=228826
where I found some untested code paths.

The first two cover the cases where there are two dots at the end and zero dots at the end.
One uses a large octal number that would overflow a uint32_t and used to be a valid URL host.

The third covers an untested case in my state machine implementation of the change
where "0x" is considered a valid IPv4 address, which is the behavior of Chrome and Safari and I believe the spec, too.

The fourth covers some cases I forgot in my initial implementation: an upper case 'X' indicating the begin of a hex number
and mixed case non-digit hex characters.

The fifth covers the non-ASCII input path.  Our recent addition of tests with xn-- and invalid punycode
leads me to believe that other browsers also have an ASCII path and a non-ASCII path for parsing URL hosts.
This covers the non-ASCII path, which was previously uncovered.