gh-157377: Don't flush the thread-local allocation count in gc.get_count

[ngoldbaum]

On the free-threaded build, gc.get_count() flushed the allocation counter into the global young count and reset it. Modifying the local count leads to pathological cases like in the linked issue. It could also flush negative local counts into the global count, which bypassed the clamp from gh-142048 and led to under-collection compared with not calling get_count().

With this change, get_count() returns the global count plus the local counter without modifying either. The reported value still includes the caller's buffered allocations, and scheduling behaves exactly as if get_count() had never been called.

• Issue: gc.get_count() can starve GC scheduling on the free-threaded build #157377

[kumaraditya303]

I think young needs to be clamped with if (young < 0) young = 0; otherwise negative values can be reported like:

xs = [[] for _ in range(600)]; gc.collect(); del xs[:400]
gc.get_count()  ->  (-173, 0, 0)     # with the PR applied

[ngoldbaum]

Makes sense and is consistent with the clamping of the global count done in gh-142048. When that happened the behavior of this function from gh-112529 was not revisited.