support defaults for typing.TypeVar and typing.TypeVarTuple

[WKarel]

Python-3.13 added optional defaults for typing.TypeVar and typing.TypeVarTuple. This PR makes stubGen.py document the defaults in stub files.

Tests fine with Python-3.14, and with test_typing.cpp containing

m.attr("T4") = nb::type_var("T4", "bound"_a = nb::builtins()["int"], "default"_a = nb::typing().attr("Literal")[1]);
m.attr("T5") = nb::type_var_tuple(
    "T5", "default"_a = nb::typing().attr("Unpack")[nb::builtins()["tuple"][nb::make_tuple(nb::type<Foo>(), nb::ellipsis())]]);

, and test_typing_ext.pyi containing

T4 = TypeVar("T4", bound=int, default=Literal[1])

T5 = TypeVarTuple("T5", default=Unpack[tuple[Foo, ...]])

But the CI runs stub tests on Python-3.10+, and doing the comparisons correctly for versions below 3.13 seems too complicated.

[wjakob]

To consider this for merging, it will need some test coverage..

[wjakob]

This seems quite complicated/fragile

[WKarel]

Depending on the Python version to be tested, up to 2 names less are imported from the typing-module, crossing stubGen.py's threshold for the maximum line length. Hence, the import-statement is either a one-liner, or it spreads across multiple lines (see my initial comment about this being too complicated to be tested). The test code thus copy/pastes stubGen.py's generation of import statements, which is ready for future changes in the number of names imported from the typing-module. But it will break in case of relevant changes of stubGen.py. An alternative would be to hard-code the resp. import-statement for different Python versions, but that seems more fragile to me. Suggestions?