gh-121464: Make concurrent iteration over enumerate safe under free-threading

[eendebakpt]

We make concurrent iteration with enumerate thread-safe (e.g. not crash, correct results are not guaranteed, see #124397) by

• Using _PyObject_IsUniquelyReferenced for the re-use of the result tuple

• In enum_next using FT_ATOMIC_LOAD_SSIZE_RELAXED/FT_ATOMIC_STORE_SSIZE_RELAXED for loading and saving of the mutable en->en_index

• In enum_next_long (and enum_reduce) we have to deal with en->en_longindex which is mutable. Since the objects in en_longindex need to be properly refcounted this is a bit hard to handle. Two options:

  i) Use a lock. This is a simple approach and the performance cost might be acceptable since use cases of enumerate with numbers that do not fit in a long are rare
  ii) The en->en_longindex can be atomically swapped with stepped_up using _Py_atomic_exchange_ptr. With this approach en->en_longindex is either zero, or has a refcount of 1. The thread performing the swap of en->en_longindex can decrement the old en->en_longindex. A branch with this approach is enumerate_ft_v3.

  In this PR we pick option i) because it is simpler and more robust.

• Issue: enum_next and pairwise_next can result in tuple elements with zero reference count in free-threading build #121464

[ethanfurman]

My expertise is with the Python-based Enum, not the C-based enumerate. Removing myself as a reviewer.

[rruuaanng]

This @staticmethod seems to be removable.

[rruuaanng]

cc @colesbury