GH-139951: Fix major GC performance regression

[markshannon]

This PR:

• Counts number of actually tracked objects, instead of trackable objects. This ensures that untracking tuples has the desired effect of reducing GC overhead
• Does not track most untrackable tuples during creation. This prevents large numbers of small tuples causing excessive GCs.

For the example in the original report this makes performance on main a bit better than 3.13.

Benchmarking results show this is about neutral on performance otherwise.

• Issue: Potentially serious regression in garbage collector performance in Python 3.14 #139951

[sergey-miryanov]

I'm not sure I get what android (x86_64) fails.
I can propose two solutions:

1. Change default value for work_to_do from -5000 to 0
2. Or remove newly added condition

if (gcstate->work_to_do < 0){return} 

[mhsmith]

I'm not at all familiar with the garbage collector, but one of the ways that Android differs from the other platforms is that it runs all the test suite serially in a single process.

[sergey-miryanov]

Code looks good to me, thanks!

[sergey-miryanov]

Should we redo the benchmarks to see how the final version impacts performance? Maybe we can run it on https://github.com/faster-cpython/benchmarking-public (but I don't know how).

[miss-islington-app]

Thanks @markshannon for the PR 🌮🎉.. I'm working now to backport this PR to: 3.14.
🐍🍒⛏🤖

[bedevere-app]

GH-140423 is a backport of this pull request to the 3.14 branch.