feat: add a generic ip_address type

[sgerbino]

From the linked review feedback ("Some thoughts on Corosio", Boost mailing list, July 2026):

I noticed that there's no generic ip_address type capable of holding either an IPv4 or an IPv6 address. The closest equivalent is corosio::endpoint, which also hold a port and is therefore not a suitable replacement.

Source: https://lists.boost.org/archives/list/boost%40lists.boost.org/message/KHNY67ZNXFWT54EIWDOJPHN4KO6KJLN4 (referenced by the Boost review result, September 2026).

endpoint already holds both ipv4_address and ipv6_address with a discriminator, so this is an extraction rather than an addition: ip_address comes out of endpoint, and endpoint reduces to ip_address + port.

Core (this issue):

• ip_address: implicit construction from ipv4_address/ipv6_address, family predicates, family-generic is_loopback()/is_multicast()/is_unspecified(), string parsing (address without port), comparison
• Conversion accessors to ipv4_address/ipv6_address: prefer a result/optional style over Asio's throwing bad_address_cast
• Decide v4-mapped v6 semantics (is_v4_mapped(), to_v4_mapped(), whether mapped forms compare equal to their v4 form) and centralize the existing ad hoc handling in native/detail/endpoint_convert.hpp
• Refactor endpoint onto ip_address + port with a single address() accessor; keep the existing ipv4_address/ipv6_address constructors working via implicit conversion; decide the fate of v4_address()/v6_address()

Follow-ons (separate issues once the core lands):

• Deduplicate the multicast socket options (join_group/join_group_v6, multicast_loop/multicast_loop_v6, ...) behind ip_address-taking options
• Host-only resolution returning ip_addresses (resolver results currently can only express address + port)

[sgerbino]

Survey of where this simplifies the existing API, from the current headers:

1. endpoint itself. It stores both an ipv4_address and an ipv6_address side by side plus a discriminator, and exposes is_v4()/v4_address()/v6_address(). The docs warn that calling the wrong accessor returns "the default any address", a silent wrong-answer path. With ip_address + port there is one address() accessor and the hazard disappears structurally.

2. Family-generic queries. "Is this loopback/multicast/unspecified" currently requires ep.is_v6() ? ep.v6_address().is_loopback() : ep.v4_address().is_loopback() in user code. On ip_address these are single predicates.

3. Parsing. endpoint(string_view) parses address+port forms, but there is no way to parse an address without a port (config files usually keep host and port separate). Today the user must try ipv4_address then ipv6_address themselves.

4. Multicast socket options. socket_option.hpp ships parallel families (join_group vs join_group_v6, multicast_loop vs multicast_loop_v6, multicast_hops_v6, multicast_interface_v6). The wire structs differ (ip_mreq vs ipv6_mreq) but a single ip_address-taking option can dispatch internally, roughly halving that section of the surface.

5. Resolver. resolver_results traffics purely in endpoints, so resolving a hostname without a service has no honest return type today (port 0 smuggling). Host-only resolution returning ip_addresses matches what getaddrinfo with a null service does.

6. Internals. native/detail/endpoint_convert.hpp carries "Must be IPv4" preconditions and hand-rolled v4-mapped logic (ep.is_v4() && socket_family == AF_INET6); centralizing mapped-address handling on ip_address gives that one tested home. The auto-open branch ep.is_v6() ? tcp::v6() : tcp::v4() in tcp_socket/udp_socket also reduces to the address family.

Asio warts to deliberately avoid: to_v4() throwing bad_address_cast (pushes users straight back into is_v4() branching; a result/optional accessor fits the error-code house style better), and the surprising inequality of a v4 address and its v4-mapped v6 form when used in ACLs.