Natively support more types with pre-defined optional hooks

Start by reviewing the Converter hook-registration APIs and global_converter, then compare the proposed register_extra_hooks variants for stdlib types such as uuid, zoneinfo, ipaddress, and re.Pattern. Done means the scope and registration behavior are agreed, including whether multiple types and third-party hooks are supported; no test path is named in the issue.

cattrs comes with a rich set of converters, but the variety of types supported by those converters out of the box is limited. Adding custom structure/unstructure hooks is pretty straightforward and well documented, and in most cases could be as trivial as in the example below. However, as an end user, I would be happy to have something even more simple, something that I wouldn't copy-paste from one project to another :)

A few ideas come to my mind:

1. What about adding a standalone function or a Converter method register_extra_hooks(converter, cls, structure=True, unstructure=True) (and its variant without first argument, defaulting to global_converter) that will cover less frequently used types from stdlib, like uuid, zoneinfo, ipaddress, re.Pattern, etc? This won't require any overhead in default case, but will enable one liner

register_extra_hooks(converter, ZoneInfo)

instead of

@converter.register_structure_hook
def structure_zoneinfo(value: Any, _) -> ZoneInfo:
    return ZoneInfo(str(value))

@converter.register_unstructure_hook
def unstructure_zoneinfo(value: ZoneInfo) -> str:
    return str(value)

2. This new function could be even generalized to accept multiple types, like

register_extra_hooks(IPv4Address, ZoneInfo)

3. It is possible to support non-stdlib modules in this function, by e.g. checking __module__ string or using inspect.getmodule() before importing third-party module itself.

4. Extra hooks could be registered by third-party libraries with e.g. pluggy.

Does anything of the mentioned above sound reasonable?