Allow int for max_warnings in TOML

[Dmao233]

Closes #14953

max_warnings was registered without a type, so native TOML integers (max_warnings = 0) were rejected even though the docs show an unquoted int.

Register it as int | str the same way as truncation_limit_*. _get_max_warnings() treats None as unset so an explicit 0 is not the empty default.

Checklist

• Include new tests or update existing tests when applicable.
• Allow maintainers to push and squash when merging my commits.
• closes #14953 in the PR description and the commit.
• Changelog file changelog/14953.bugfix.rst.
• Added myself to AUTHORS in alphabetical order.
• AI assistance is credited in a Co-authored-by trailer.

[Pierre-Sassoulas]

Looks reasonable thank you.

[Pierre-Sassoulas]

We don't need those automated tests, the int | str mechanism is already tested elsewhere.

[Amine-LG]

Thanks. I tested the current head, 72679ce2, directly against its base, 5d85267e. Native TOML integer zero is accepted as intended, but I also observed these changes:

Case	Base	Current head
Option unset	getini() returns "" (str)	Returns None
INI max_warnings = 0	Returns "0" (str)	Returns 0 (int)
-o max_warnings=0	Returns "0" (str)	Returns 0 (int)
Empty value in INI/-o, or max_warnings = "" in TOML	Treated as unset	Reaches int(""), raises ValueError, and exits 1 after the test runs
Native TOML max_warnings = 0	Rejected with exit 4	Enforced with MAX_WARNINGS_ERROR, exit 6

I have three questions:

1. Are the changes to the existing Config.getini() return values intentional? I reran the str | int, default="" direction described in max_warnings rejects the integer shown in the native TOML documentation #14953, and it accepts native TOML integers while preserving the base values above.

2. If empty values are now intended to be invalid, should they be rejected as a configuration usage error instead of producing a raw ValueError during session finish after the test has run?

3. f2141d7 removed the 96-line test block following the review feedback, while 72679ce restored the same block unchanged. Was the restoration intentional? If so, which max_warnings-specific behavior requires the full matrix rather than one focused end-to-end native TOML zero regression plus any compatibility case retained above?

[Dmao233]

Addressed in f4d3a6c.

1. Not intentional. Switched to str | int with default "", so getini keeps the base string/"" behavior; native TOML ints still work.
2. Empty values stay treated as unset, same as base.
3. The earlier restore was a mistake. Kept one native TOML zero regression only (test_max_warnings_toml_native_int_zero), dropped the rest per Pierre.

[Amine-LG]

Thanks. I reran f4d3a6ce and confirmed that the base behavior for unset, INI, -o, and empty values is now preserved, while native TOML integer 0 remains accepted and enforced.

This resolves the discrepancies identified in the comparison above.