gh-128137: Update PyASCIIObject to handle interned field with the atomic operation

[corona10]

• Issue: Race in PyUnicode_InternFromString under free-threading #128137

[corona10]

@colesbury I am not sure what you intended.
To maintain the original size, I squeeze the state field from 32 bits to 16 bits and reserve 16 bits for the interned field.

[corona10]

f30b355 breaks WASI test: https://github.com/python/cpython/actions/runs/12469477403/job/34802702354?pr=128196 (object size is increased).

[colesbury]

I think this remain in the state struct. It's okay for a struct to contain both non-bitfield and bitfield members:

• It avoids a potential unnecessary breakage from moving the field
• Keeping it in state will make it easier to keep state 32-bits due to alignment.

[colesbury]

I think this should have a NEWS entry given that we're changing the size of a semi-public field.

[corona10]

Since we touch the semi-public field, I am not sure about backporting this PR.
Let's just leave 3.13t as buggy status because it is just the experimental build.

[corona10]

@colesbury

I use unsigned short, which is supported by specific compilers as the same as unsigned char, and I attach related links about it.
And I am fine with if we can cover PEP 11 platforms.

• gcc: https://gcc.gnu.org/onlinedocs/gcc/Structures-unions-enumerations-and-bit-fields-implementation.html
• clang: Normally follow gcc's behavior. (No official implemenatation detail manual exists about it document implementation-defined behavior llvm/llvm-project#11644)
• MSVC: https://learn.microsoft.com/en-us/cpp/c-language/c-bit-fields?view=msvc-170
• IBM XL: https://www.ibm.com/docs/en/xcfbg/121.141?topic=modes-alignment-bit-fields

But if we want to forget about 4 bytes increasement issue at 32 bit platforms, and just use portable bit field declaration could be one possible option. Because we can just add specific unit test handling code for specific platforms but I don't prefer this option because it is very difficult to track platform specific issue in the future.

[bedevere-bot]

🤖 New build scheduled with the buildbot fleet by @corona10 for commit 30c2eb2 🤖

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

[corona10]

Ah, okay, I re-read https://bugs.python.org/issue19537; unsigned short is not proper, so I revert to using unsigned char instead. It will be correct. (But I need to investigate Windows issue again)

[bedevere-bot]

🤖 New build scheduled with the buildbot fleet by @corona10 for commit 91907aa 🤖

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

[corona10]

I think that it would be fine

• uint16_t: interned field = 16bits (Increase it to 16bits is little bit painful, but it would be nothing for modern CPUs)
• unsigned short: kind + compact + ascii + statically_allocated + padding = 16bits (for 32bits and 64bits system both)
• In total: 32 bits

[corona10]

In Linux

• sizeof PyASCIIObject is 40bytes
• sizeof PyASCIIObject.state is 4 bytes.

So no regression will be.

[colesbury]

This LGTM. @methane, would you please take a look at this as well?