BUG: descriptor accessors should account for struct padding on 32bit abi3t builds #31762

This was first seen in PyO3/rust-numpy#556

The flags field of the PyArray_Descr_fields struct is explicitly 64 bits:

On the 32-bit free-threaded build, sizeof(PyObject) is 20 bytes. On the 32 GIL-enabled build it's 8 bytes.

The combination of these facts have annoying implications for 32-bit Python abi3t builds, given our current field access implementation.

On the free-threaded build, type_num is at 28 bytes, so flags is at 32 bytes and no padding is necessary. On the 32 bit GIL-enabled build, the type_num starts at offset 16, so flags must be padded from 20 to 24 bytes to stay 8-byte aligned.

This throws off the way we implemented access for flags and all fields after flags on abi3t, since all accesses go through the _PyDataType_GET_ITEM_DATA function and there are now two different offsets we need to deal with for flags and every field after.

I think at a minimum we need to add at least one new API function to account for whether or not the padding bytes exist for accesses on flags and all fields after flags. On abi3t, the offset calculation needs to happen in NumPy internals, and it's the only place that can know at runtime if the interpreter is free-threaded or not.

On 64 bit, the PyObject sizes on free-threaded and GIL-enabled builds are 32 bytes and 16 bytes, respectively. These are both 8-byte aligned and we don't notice this issue.

I had an attempt at a fix for this in #31759. The fix is wrong (it breaks the GIL-enabled 32 bit build) but the test I added might be helpful.