gh-115999: Add free-threaded specialization for CONTAINS_OP

[corona10]

• Issue: Make the specializing interpreter thread-safe in --disable-gil builds #115999

[corona10]

I just followed up on the change #126410. The specialization mechanism of this opcode is the same with COMPARE_OP IIUC, so it should be added too.

[mpage]

Thanks! Would you please add a short explanation to either the pull request description or commit message outlining why the specialization logic + specialized instructions are thread-safe? I think what's here is correct, but it would be helpful for someone unfamiliar with this code, or if it turns out that our assumptions are invalid.

In this case, I think something like the following would be fine:

• The specialization logic determines the appropriate specialization using only the operand's type, which is safe to read non-atomically (changing it requires stopping the world). We are guaranteed that the type will not change in between when it is checked and when we specialize the bytecode because the types involved are immutable (you cannot assign to __class__ for exact instances of dict, set, or frozenset). The bytecode is mutated atomically using helpers.
• The specialized instructions rely on the operand type not changing in between the DEOPT_IF checks and the calls to the appropriate type-specific helpers (e.g. _PySet_Contains). This is a correctness requirement in the default builds and there are no changes to the opcodes in the free-threaded builds that would invalidate this.