Update spawn context for multiprocessing

[kratman]

Description

Fixes the spawning issue from my attempts to update to numpy 2.0.0 and switches to macos-latest

Type of change

Please add a line in the relevant section of CHANGELOG.md to document the change (include PR #)

Important checks:

Please confirm the following before marking the PR as ready for review:

• No style issues: nox -s pre-commit
• All tests pass: nox -s tests
• The documentation builds: nox -s doctests
• Code is commented for hard-to-understand areas
• Tests added that prove fix is effective or that feature works

[codecov[bot]]

Codecov Report

:white_check_mark: All modified and coverable lines are covered by tests. :white_check_mark: Project coverage is 99.12%. Comparing base (6dc7fd0) to head (a673ed0). :warning: Report is 168 commits behind head on develop.

Additional details and impacted files

@@             Coverage Diff             @@
##           develop    #5084      +/-   ##
===========================================
- Coverage    99.12%   99.12%   -0.01%     
===========================================
  Files          305      304       -1     
  Lines        23557    23573      +16     
===========================================
+ Hits         23351    23366      +15     
- Misses         206      207       +1     

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

:rocket: New features to boost your workflow:

• :snowflake: Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[kratman]

@BradyPlanden I could not reproduce the original issue when testing this, and fork() on MacOS seems to be problematic with numpy 2.0.0 and the ScipySolver

If you can find a new example where this fails, then we can revisit it, but for now MacOS should stay with the spawn method for multiprocessing

[BradyPlanden]

Thanks @kratman! I haven't had time to investigate in-depth; however, I did check that this doesn't affect the multiprocessing setup in PyBOP, and I can confirm that dependent packages don't appear to be affected. I don't think this is surprising, though, given the difference in how we multiprocess. I suspect the reason the main defending issue isn't cropping up in the CI is due to the change to the default solver to IDAKLU, as multiprocessing occurs within the solver. Looks fine from side, given that the aim is to further align the IDAKLU as the core solver.