GH-133136: Revise QSBR to reduce excess memory held

[nascheme]

This is a refinement of GH-135107. Additional changes:

• track the size of the mimalloc pages that are deferred
• introduce _Py_qsbr_advance_with_size() to reduce duplicated code
• adjust the logic of when we advance the global write sequence and when we process the queue of deferred memory
• small fix for the goal returned in the advance case, it is safe to return the new global write sequence, not the next write sequence

With these changes, the memory held by QSBR is typically freed a bit more quickly and the process RSS stays a bit smaller.

Regarding the changes to advance and processing, GH-135107 has the following minor issues: if the memory threshold is exceeded when a new item is added, by free_delayed(), we immediately set memory_deferred = 0 and process. It is very unlikely that the goal has been reached for the newly added item. If that's a big chunk of memory, we would have to wait until the next process in order to actually free it. This PR tries to avoid that by storing the seq (local read sequence) as it was at last process time. If that hasn't changed (this thread hasn't entered a quiescent state) then we wait before processing. This at least gives a chance that other readers will catch up and the process can actually free things.

This PR also changes how often we can defer the advance of the global write sequence. Previously, we deferred it up to 10 times. However, I think there is not much benefit to advancing it unless we are nearly ready to process. So, the should_advance_qsbr() is checking if it seems time to process. The _Py_qsbr_should_process() checks if the local read sequence has been updated. That means the write sequence has advanced (it's time to process) and the read sequence for this thread has also advanced. This doesn't tell us that the other threads have advanced their read sequence but we don't want to pay the cost of checking that (would require "poll").

pyperformance memory usage results

• Issue: Memory keeps increasing with fixed-size dict during multi-threaded set/delete in 3.13.3t #133136