Use "spawn" instead of "fork" multiprocessing

Describe the bug

Parallel build hangs with some libraries as multiprocessing "fork" start method is unreliable and breaks multithreading:
https://docs.pola.rs/user-guide/misc/multiprocessing/
https://github.com/pola-rs/polars/issues/7535
This becomes an issue when custom sphinx hooks using such libraries are used.

Fundamentally, the "fork" method is somewhat broken as cannot generally be expected to work. I'm not sure what is the best way to handle that considered "spawn" is a lot slower (requires re-importing modules), but maybe it's ok with a long-lived pool.

How to Reproduce

I haven't managed to drill down a minimal reproducer unfortunately. The issue happens when calling polars.LazyFrame.collect() in our case, as this will trigger multithreaded work in an extension module (Rust code of polars, probably does not hold the GIL for all the computations but allows Python callbacks so it must to some extent, sometimes).

Environment Information

Platform:              linux; (Linux-5.15.0-92-generic-x86_64-with-glibc2.31)
Python version:        3.11.7 (main, Dec  8 2023, 18:56:57) [GCC 9.4.0])
Python implementation: CPython
Sphinx version:        7.2.6
Docutils version:      0.20.1
Jinja2 version:        3.1.3
Pygments version:      2.17.2

Sphinx extensions

No response

Additional context

No response

No source file or test is named. Start by reproducing the parallel build with a custom Sphinx hook that calls polars.LazyFrame.collect(), then trace the multiprocessing entry point and its fork/spawn handling. Done means the affected build no longer hangs with multithreaded extension work and existing parallel-build behavior remains covered.