Add `duration` and `visited` to the `gc.callbacks` and `gc.get_stats()` dicts

[brandtbucher]

Feature or enhancement

The documentation for gc.callbacks states that its primary use cases are:

Gathering statistics about garbage collection, such as how often various generations are collected, and how long the collection takes.

We can be doing a bit more to serve users of gc.callbacks (and gc.get_stats() too). In particular:

• duration: Collection time, which is mentioned above, is something we already have a low-overhead mechanism to measure for use with the gc.DEBUG_STATS flag. It's a bit finnicky to get right in a callback, since they're called in two phases (so the start time has to be stashed away somewhere between calls).
• visited: The number of visited objects is also extremely useful (collected/visited gives you the efficiency of your collection). Getting this information from Python is very expensive (sum(len(gc.get_objects(g)) for g in range(gen + 1))), but it's cheap for us to provide from the GC itself.

With these changes, many users can probably get away with just handling stop events, or ditching callbacks entirely and just periodically checking gc.get_stats() instead for aggregates.

I already ran this idea by @nascheme and @markshannon this week. They were supportive of the idea, so I plan on working on this soon.

(Supersedes #140515.)

Linked PRs

• GH-140638: Add a GC "duration" stat #141720
• GH-140638: Add a GC "candidates" stat #141814

[nascheme]

I think this is a good idea, assuming we can do it with nearly zero cost. Some thoughts:

• tuples containing non-GC objects are untracked. The cheap thing to do is not count them. GC is not spending time on them so maybe that makes sense. OTOH, if we change something that causes less objects to be untracked, the per-object time stats wouldn't show that regression.
• what about gc.freeze()? Again I guess we don't count frozen containers.
• Within the GC implementation, the term "visit" is used for following object graph edges. So "number of visited objects" makes me think edges. However, I think Brandt wants to count vertices (which I think makes sense, OCaml's GC reports GC time on a per-object basis). Saying "unique objects visited" seems a bit unwieldy but is perhaps more accurate to what we are counting.
• With the free-threaded GC, I wonder if it could become expensive to count objects. I had a vague idea that we could implement incremental collection by marking the generation on mimalloc areas (maybe requires write barriers, I don't know). If we had such a thing, we would skip walking those arenas. I guess we shouldn't count those objects in that case, since the GC is not visiting them.

[brandtbucher]

Leaving this open so I can explore untracked and marked stats as suggested in the most recent PR.