Io.net.Ip6Address parse failures related to embedded IPv4 forms

[blblack]

Zig Version

0.16.0-dev.1301+cbfa87cbe

Steps to Reproduce and Observed Behavior

1. It currently short-circuits any input starting with ::ffff: to assume only an IPv4 dotted-quad can exist at the end. It should be legal to parse addresses in this range in non-canonical form, e.g. ::ffff:c000:201 (which currently fails to parse) should parse equivalently to ::ffff:192.0.2.1.

2. It should accept the IPv4 dotted-quad form at the end of any preceding legitimate representation of the first 12 bytes. There is no requirement on the parsing side that this form only exist within the IPv4 Mapped space (see RFC 4291 Sec 2.2.3 "alternative form"), or any other particular subset of fixed, well-known spaces. Currently the parser fails on many real-world cases like 64:ff9b::192.0.2.1 (the "Well-Known Prefix" from RFC 6052), ::192.0.2.1 (the deprecated "IPv4 Compat" space, which some IP databases still use for v4 embedding), and/or any arbitrarily-locally-defined spaces for various tunneling / transition schemes.

Expected Behavior

That our IPv6 parser parses all standards-based textual representations of IPv6 addresses, including the full x:IPv4 "alternate form".