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.

[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?