gc used several PySys_WriteStderr() calls to write stats.
This caused stats mixed up when stderr is shared by multiple
threads or processes.

Attached file (t.py) demonstrates it.
Sometimes stats from two processes are mixed up like this:

```
gc: collecting generation 0...
gc: objects in each generation: 782 0 7759
gc: objects in permanent generation: 0gc: collecting generation 0...

gc: objects in each generation: 782 0 7764
gc: objects in permanent generation: 0gc: done, 781 unreachable, 0 uncollectable, 0.0001s elapsed

gc: done, 781 unreachable, 0 uncollectable, 0.0000s elapsed
```

Writing one stat by one PySys_WriteStderr() reduces this.

Delaying the write means you don't get an indication of the steps in the process; if someone is trying to debug a crash caused by corruption of the gc list (e.g. due to a bad extension module), deferring the writes means they won't see any output before the crash, where before, they'd see:

gc: collecting generation 0...
gc: objects in each generation:

and numbers for however many gc list traversals succeeded before the corrupt entry in the gc list was hit.

I updated the PR to show "gc: collecting generation 0...\n" before counting objects in each generations.

New changeset bf8162c8c45338470bbe487c8769bba20bde66c2 by Inada Naoki in branch 'master':
bpo-37729: gc: write stats at once (GH-15050)
https://github.com/python/cpython/commit/bf8162c8c45338470bbe487c8769bba20bde66c2

New changeset e8ea34855c7635f8a84b430f17dc01a666f4c0ef by Inada Naoki (Miss Islington (bot)) in branch '3.8':
bpo-37729: gc: write stats at once (GH-15050)
https://github.com/python/cpython/commit/e8ea34855c7635f8a84b430f17dc01a666f4c0ef

See Issue37990 for a report of a regression introduced by these changes.