gh-103059: Move fork advice from gc.freeze to gc.disable

The current advice seems to mean you should gc.disable() and gc.freeze()
right before os.fork(), which doesn't do anything.

Łukasz explained the advice in
https://bugs.python.org/issue31558#msg302780.

This moves the advice around gc.disable out of the gc.freeze docs.

Author: raylu

Doc/library/gc.rst

@@ -32,6 +32,14 @@ The :mod:`gc` module provides the following functions:
 
    Disable automatic garbage collection.
 
+   This can be useful for a process that will fork() but not exec() to do at
+   the beginning of the parent's execution. When the collector runs in the
+   parent, it leaves space scattered throughout memory pages for new objects.
+   Those pages become shared as copy-on-write pages with the child after forking.
+   When the child starts allocating objects, it writes to those pages, causing
+   the kernel to copy them, including all the garbage data the parent had
+   already collected. Remember to re-enable collection in the child.
+
 
 .. function:: isenabled()
 
@@ -209,9 +217,9 @@ The :mod:`gc` module provides the following functions:
    Freeze all the objects tracked by gc - move them to a permanent generation
    and ignore all the future collections. This can be used before a POSIX
    fork() call to make the gc copy-on-write friendly or to speed up collection.
-   Also collection before a POSIX fork() call may free pages for future
-   allocation which can cause copy-on-write too so it's advised to disable gc
-   in parent process and freeze before fork and enable gc in child process.
+   Otherwise, when the child process accesses objects allocated in the parent,
+   the gc_refs counter will be incremented, triggering copy-on-write and
+   consuming more memory.
 
    .. versionadded:: 3.7
 

Misc/ACKS

@@ -1113,6 +1113,7 @@ Jason Lowe
 Tony Lownds
 Ray Loyzaga
 Kang-Hao (Kenny) Lu
+Raymond Lu
 Lukas Lueg
 Loren Luke
 Fredrik Lundh