Prepare salt.utils.process for python 3.14

[marmarek]

What does this PR do?

Python 3.14 changed multiprocessing method from 'fork' to 'forkserver' on Linux too:
python/cpython#84559

This leads to issue similar to when Python 3.8 changed it on Mac OS: #57742

Change the condition to check for != 'fork' instead of == 'spawn'.

Question: should salt.util.platform.spawning_platform() be changed instead? forkserver isn't exactly the same as spawn, but it's more similar to it than to fork.

What issues does this PR fix or reference?

Related to #68148

Previous Behavior

Fails similar to #57742 on Linux with Python 3.14 (Fedora 43 beta)

New Behavior

Doesn't crash anymore

Merge requirements satisfied?

[NOTICE] Bug fixes or features added to Salt require tests.

• Docs
• Changelog - https://docs.saltproject.io/en/master/topics/development/changelog.html
• Tests written/updated

Commits signed with GPG?

Yes

[twangboy]

I think it makes more sense to modify salt.util.platform.spawning_platform(), but let's have @dwoz weigh in.

[aphor]

I found this as well. I fixed it by hacking multiprocessing.set_start_method('spawn') into salt.scripts.salt_master() because Python-3.14 seems to default to 'forkserver' and it seemed like the best way to conform to salt's expectations.

def salt_master():
    """
    Start the salt master.
    """
    import salt.cli.daemons
    import multiprocessing

    multiprocessing.set_start_method('spawn')

    # Fix for setuptools generated scripts, so that it will
    # work with multiprocessing fork emulation.
    # (see multiprocessing.forking.get_preparation_data())
    if __name__ != "__main__":
        sys.modules["__main__"] = sys.modules[__name__]

    master = salt.cli.daemons.Master()
    master.start()

[Sxderp]

Does it make sense to switch all platforms to 'spawn'? Or do some not support it?