We make concurrent iteration overitertools.pairwise safe by:

• Using_PyObject_IsUniquelyReferenced for re-use of the result type
• Holding a reference topo->it instead of a borrowed reference
• Obtaining a reference topo->old early.

Also see#123848

To makepairwise_next safe we need to prevent concurrent iterators from accessing the clearedpo->it

• Idea 1: In the first line ofpairwise_next replacePyObject *it = po->it withPyObject *it = Py_XInRef(po->it);.
  Then every thread will have a true reference to the iterator, and not a borrowed reference.
  Simple, but overhead is an incref/decref in the common case
• Idea 2a: Do not clearpo->it. We then need another way to signal that the iterator has been exhausted.
  Use another variable "int iterator_exhausted" in the pairwise object. Requires a bit more memory
  for each pairwise object, but the check is a simple int comparison.
• Idea 2b: Do not clearpo->it. We then need another way to signal that the iterator has been exhausted.
  Usepo->old to set a sentinel. Requires a global sentinel in the module (or a sentinel per thread).
  In the top ofpairwise_next we would have

PyObject *old = Py_XNewRef(po->old);if (old == sentinel) {      // iterator was exhausted earlier, return NULL      Py_DECREF(old)      return NULL;}if (old == NULL) {      // first call to pairwise_next, normal code      ...}

An issue with this approach is that at the end of pairwise_next there is the line:Py_XSETREF(po->old, new);
So one thread can set the sentinel, but in another thread the value could be overwritten.
Maybe this is ok: this will not cause crashes, and we do not have to guarantee correct behaviour for
the free-threading build.
This approach does not require additional increfs/decrefs, but it does require setting up the sentinel.

In this PR we work out the first option.

• Issue:Make concurrent iteration over pairwise, combinations, permutations, cwr, product, etc. from itertools safe under free-threading #123471