PERF: speed up strftime for common format directives

[jbrockmendel]

Summary

• For formats composed of common directives (%Y, %m, %d, %H, %M, %S, %f), parse the format string once into a str.format() template and format directly from npy_datetimestruct fields, avoiding per-element Timestamp creation.
• For tz-aware data, converts UTC to local time via Localizer.utc_val_to_local_val before extracting struct fields (works because _convert_strftime_format returns None for formats containing %z/%Z).
• Unsupported directives (%A, %B, %z, %Z, etc.) fall back to the existing per-element Timestamp.strftime() path.

Benchmarks (10.5M elements, %Y/%m/%dT%H:%M:%S)

Scenario	Before	After	Speedup
tz-naive	~28s	6.7s	4.2x
UTC	~28s	6.7s	4.2x
US/Eastern	~28s	9.9s	2.8x

• closes PERF: strftime is slow #44764

Test plan

• All 144 existing strftime tests pass
• IO format tests pass (2295 passed)
• Correctness verified against per-element Timestamp.strftime() for multiple formats
• Verified NaT handling (tz-naive and tz-aware)
• Verified fallback for unsupported directives (%A, %Z)
• Verified tz-aware correctness for UTC, US/Eastern (DST transitions), fixed-offset

🤖 Generated with Claude Code

[jbrockmendel]

Possible follow-up: C snprintf path

If we need more speed, there's a straightforward follow-up that gets the custom-format path close to the hardcoded f-string performance. Instead of str.format(), use C snprintf with POSIX positional specifiers (%1$ld, %2$02ld, etc.) to format the npy_datetimestruct fields directly into a stack buffer, then decode to a Python string. This avoids all Python method dispatch overhead in the inner loop.

On my machine (10.5M elements, %Y/%m/%dT%H:%M:%S):

• Current .format() path: 6.7s
• With snprintf: 2.8s
• Hardcoded f-string path: 1.8s

The implementation is simple — always pass all 7 struct fields in fixed order, and the template references them by position — but POSIX positional specifiers aren't available on Windows, so it would need a runtime check (_check_posix_snprintf()) and fall back to .format() on Windows. I had this working in an earlier iteration of this PR but stripped it out to keep the diff reviewable.

[mroeschke]

We support replacement brackets in a format string like `format="%Y-{1:02d}"? Do we have tests for this case?

[jbrockmendel]

will add a test

[mroeschke]

Thanks @jbrockmendel