gh-128715: Expose ctypes.CField, with info attributes

[encukou]

Expose the type of struct/union field descriptors (_ctypes._CField) as ctypes.CField. (This is mainly to make it easier to refer to it -- for typing and documentation. Creating CFields manually is not supported.)

Add attributes for easier introspection:

• name & type, as defined in _fields_
• byte_size & byte_offset, specify the chunk of memory to read/write
• bit_size & bit_offset, which specify the shift & mask for bitfields
• is_bitfield & is_anonymous booleans

The existing offset remains, as an alias for byte_offset.
The existing size is unchanged. Usually it is the same as byte_size, but for bitfields, it contains a bit-packed combination of bit_size & bit_offset.

Update the repr() of CField.

Use the same values internally as well. (Except bit_size, which might overflow Py_ssize_t for very large types. Instead, in C use bitfield_size, which is 0 for non-bitfields and thus serves as is_bitfield flag. Different name used clarity.)
Old names are removed from the C implementation to ensure a clean transition.
For simplicity, I keep byte_size in CFieldObject for now, even though it's redundant: it's the size of the underlying type.

Add a generic test that ensures the values are consistent, and that we don't have overlapping fields in structs. Use this check throughout test_ctypes, wherever a potentially interesting Structure or Union is created. (Tests for how simple structs behave after they're created don't need the checks, but I erred on the side of adding checks.)

Lift the restriction on maximum field size that was temporarily added in GH-126938. The max size is now Py_ssize_t.

This PR does not yet touch cfield.c getters & setters: the bit-packed “size” argument is computed and passed to those.

• Issue: Untangle ctypes bitfield size and expose field information #128715

---

📚 Documentation preview 📚: https://cpython-previews--128950.org.readthedocs.build/

[encukou]

I'll continue next week :)

[picnixz]

Should I review what you wrote now or do you prefer me to wait?

[encukou]

Sorry, I missed the comment! I'd appreciate a review.

The failure on 32-bit Debian is due to an existing bug, but such an exotic one that it's not worth fixing now: #130410
(It shows that the tests work, though!)

[encukou]

@picnixz, should I wait for your review?
No pressure, feel free to say no :)

[picnixz]

Oh I forgot... I'll have maybe a bit of time before taking my plane or I'll be back on Wednesday. If you want to wait until then, I'll review it otherwise just go ahead!

[picnixz]

Some comments (hard to do a better review on a phone)

[encukou]

Thank you for the review!

[encukou]

Thanks for the reviews everyone!
I'll merge tomorrow if there are no objections.

[picnixz]

I don't think I've much more to say. My main concern was the unicode-exactness of the name which is now resolved so I'm fine.

[bedevere-bot]

🤖 New build scheduled with the buildbot fleet by @encukou for commit 5ce595c 🤖

Results will be shown at:

https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F128950%2Fmerge

If you want to schedule another build, you need to add the 🔨 test-with-buildbots label again.

[encukou]

Almost tomorrow.... :)

Thank you for the reviews, everyone!