Currently, multiprocessing has hard-coded logic to re-seed the Python random generator (in the random module) whenever a process is forked.  This is present in two places: `Popen._launch` in `popen_fork.py` and `serve_one` in `forkserver.py` (for the "fork" and "forkserver" spawn methods, respectively).

However, other libraries would like to benefit from this mechanism.  For example, Numpy has its own random number generator that would also benefit from re-seeding after fork().  Currently, this is solvable using multiprocessing.Pool which has an `initializer` argument.  However, concurrent.futures' ProcessPool does not offer such facility; nor do other ways of launching child processes, such as (simply) instantiating a new Process object.

Therefore, I'd like to propose adding a new top-level function in multiprocessing (and also a new Context method) to register a new initializer function for use after fork().  That way, each library can add its own initializers if desired, freeing users from the burden of doing so in their applications.