gh-109653: Defer importing warnings in several modules

[AlexWaygood]

warnings is a pretty cheap import, so the import-time saving from deferring it is usually pretty minimal. However, it's also a textbook example of an import that should be deferred wherever reasonable. Most of the time, it's only imported so that a DeprecationWarning can be emitted, and we should try to make it so that users only have to pay the (small) performance penalty from it being imported if they actually hit the specific code path that's deprecated.

Nonetheless, since the performance impact of importing warnings is so small, I've tried to avoid modules that make multiple uses of warnings -- it's not particularly DRY to have import warnings repeated several times in the same module. The one exception I made here is argparse: argparse really should be importing the absolute minimum set of modules given that it's a CLI framework (see #74338 for previous discussion).

• Issue: Improve import time of various stdlib modules #109653

[hauntsaninja]

Thanks, look good!

This is somewhat marginal. On my laptop, the time it takes to import warnings is below the noise floor. On another system I have access to, it looks like it's about 0.3ms. (Both measuring Python 3.11 builds)

λ hyperfine --warmup 3 'python -c "pass"' 'python -c "import warnings"'
Benchmark 1: python -c "pass"
Time (mean ± σ): 39.0 ms ± 1.4 ms [User: 30.8 ms, System: 8.3 ms]
Range (min … max): 34.4 ms … 41.3 ms 78 runs
Benchmark 2: python -c "import warnings"
Time (mean ± σ): 39.3 ms ± 1.9 ms [User: 28.9 ms, System: 10.4 ms]
Range (min … max): 30.4 ms … 47.0 ms 69 runs
Summary
python -c "pass" ran
1.01 ± 0.06 times faster than python -c "import warnings"

[AlexWaygood]

Yeah, definitely not the biggest contributor to import-time issues, but probably one of the easiest to tackle :)

Thanks for the review!