Add stubs for stdlib `_colorize` module

Description

_colorize was introduced in 3.13, and has been steadily growing since then.

From (https://github.com/python/cpython/issues/133346), I got the impression that the naming is due to unfortunate timing:

Rename _colorize to colorize

There's frankly very little time for this before Python 3.14 beta 1. I would rather keep the library name underscored for 3.14 and gather feedback from the community on the format and behavior, and introduce a stable API in Python 3.15, keeping _colorize for backward compatibility.

Interestingly, _colorize is already fully-typed (https://github.com/python/cpython/blob/main/Lib/_colorize.py).
I'm here because the absence in _typeshed means this example [^1] can produce errors in some type checkers:

[^1]: Adapted from a comment in _colorize

from typing import reveal_type

try:
    from _colorize import ANSIColors, Syntax, default_theme, set_theme
except ImportError:
    pass
else:
    reveal_type(set_theme)
    theme_with_dim_operators = default_theme.copy_with(syntax=Syntax(op=ANSIColors.INTENSE_BLACK))
    set_theme(theme_with_dim_operators)
    del set_theme, default_theme, Syntax, ANSIColors, theme_with_dim_operators

This checks out fine with pyright, but both pyrefly and ty seem to not know about _colorize yet.
Perhaps adding to typeshed would help?

Related

• https://github.com/python/cpython/issues/133346
• https://docs.python.org/3.15/whatsnew/3.15.html#whatsnew315-more-color
• https://github.com/python/cpython/pull/118283

Start by reading CPython's Lib/_colorize.py and compare its typed definitions with the standard-library stubs in typeshed. Check the provided reveal_type example with pyright, pyrefly, and ty; done means the _colorize names and signatures are recognized consistently without errors.