GH-91432: Implement the FOR_ITER_SET specialization

[corona10]

Microbenchmark

result: Mean +- std dev: [base] 662 ns +- 5 ns -> [FOR_ITER_SET] 616 ns +- 2 ns: 1.07x faster

import pyperf

runner = pyperf.Runner()
runner.timeit(name="set iter",
              stmt="""
for e in s:
    pass
""",
              setup = """
s = set(range(100))
"""
              )

Leak test

➜  cpython git:(gh-91432) ✗ ./python.exe -m test test_set -R 3:3
Raised RLIMIT_NOFILE: 256 -> 1024
0:00:00 load avg: 7.62 Run tests sequentially
0:00:00 load avg: 7.62 [1/1] test_set
beginning 6 repetitions
123456
......

== Tests result: SUCCESS ==

1 test OK.

Total duration: 23.3 sec
Tests result: SUCCESS

I just follow @sweeneyde's work.
(Following the faster CPython project is kind of my daily hobby ;) Sorry if you already worked on your local branch.. )
According to his stat, set iteration (3.8%) would be worth optimizing as same as tuple iteration (2.8%)
This PR would be decided to be merged after #94096 is merged.

[markshannon]

Is iteration over sets common enough to justify this?
The stats on pyperformance suggest it is only ~3% of FOR_ITER executions.

Our main motivation for specializing FOR_ITER is to allow us to iterate over generators without making C calls and without slowing down iterating over sequences.

[corona10]

@markshannon
Thanks, yeah stat looks changed from https://gist.github.com/sweeneyde/e1a7e98890e75c9355f99067b03ee37b.
(What makes change?)
dict keys and ascii string is more worth to specializing them.
It seems that all I can defend is that the numbers are lower than theirs(dict keys, ascii string) but are similar lol.

I am okay not applying this change if this is not worth specializing in the operation.
Can we run the performance benchmark? (Sorry, I don't have the physical machine to run this.. )
if there is no contribution to performance improvement, I am fine to not specialize it.

[markshannon]

The change in stats is presumably from merging #91713

I'll run pyperformance on this PR, but its in the queue behind #94109, so might take a while...

[corona10]

Suggested change

	static PyObject *setiter_iternext(_PySetIterObject *si) {
	PyObject *stack[1];
	int err = _PySetIter_GetNext(si, stack);
	if (err <= 0) {
	return NULL;
	}
	return stack[0];
	}
	static PyObject *setiter_iternext(_PySetIterObject *si) {
	PyObject *key;
	if (_PySetIter_GetNext(si, &key) <= 0) {
	return NULL;
	}
	return key;
	}

might be better

[markshannon]

Performance shows a 1% speedup, although I think this just shows that 1% variations can be caused by code layout changes and other build effects.

Projecting from stats, FOR_ITER_SET would represent about 0.03% of executed instructions. (FOR_ITER_ADAPTIVE is 0.8% and of that only 4% are sets.)

I doubt that any further specialization of FOR_ITER is worthwhile.

[corona10]

@markshannon agree Let's close the PR!