Currently when the mutator allocates, the runtime first allocates the memory and then, if that G has done "enough" allocation, the runtime checks whether the G has assist debt to pay off and, if so, pays it off. This approach permits various ways of under-assisting:

1. Large allocations can push the system arbitrarily over the heap goal because they're satisfied before the assist pushes back. A single G can only push the heap size over the goal by its largest single allocation, but if there are many Gs doing large allocations, we can go over the heap goal by the total of these allocations. (There's no way to 100% solve this problem since a G can always do a single allocation that's more than the heap goal, but this is a very specific case.)
2. If a G has racked up debt and then exits, that debt disappears. This isn't likely to cause problems if it's just one G, but, as above, if a large number of Gs do this, the system can fall arbitrarily far behind on assisting.

We should flip this around and do the assist first to ensure that a mutator always has sufficient credit to allocate memory when it does so. We can continue to amortize the cost of assists by requiring that they over-assist when triggered to build up credit for many allocations. Note that we can't completely eliminate the possibility of debt because there are situations in which we can't assist (e.g., allocations in non-preemptible contexts), but these are at least under the runtime's control.

This requires a little restructuring of mallocgc, but should be fairly easy.

This was suggested by @dvyukov in #11677 (comment).

@RLH @rsc