Enabling std::execution::par for Clang 17+ and libc++

[alex-w]

Enabling support of parallel algorithms for Clang 17+ and libc++ (like FreeBSD) via adding -fexperimental-library option for compiler. Of course other way to use parallel algorithms is adding Intel's oneDPL (Intel's oneAPI) library.

See:

• https://oneapi-src.github.io/oneDPL/parallel_api/execution_policies.html
• https://forum.juce.com/t/c-support-for-execution-policies-on-ios/61261/3
• https://stackoverflow.com/questions/74722155/stdboyer-moore-searcher-and-stdexecutionpar-not-available-on-appleclang-14
• https://github.com/llvm/llvm-project/issues/57898

Our CI instance FreeBSD/Clang 18 is passed the test

Type of change

• [ ] Bug fix (non-breaking change which fixes an issue)
• [ ] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)
• [ ] This change requires a documentation update
• [x] Housekeeping

Checklist:

• [ ] My code follows the code style of this project.
• [ ] I have performed a self-review of my own code
• [ ] I have commented my code, particularly in hard-to-understand areas
• [ ] I have made corresponding changes to the documentation (header file)
• [ ] I have updated the respective chapter in the Stellarium User Guide
• [ ] My changes generate no new warnings
• [ ] I have added tests that prove my fix is effective or that my feature works
• [ ] New and existing unit tests pass locally with my changes
• [ ] Any dependent changes have been merged and published in downstream modules

[10110111]

Is this sorting parallelization so crucial for performance that we want to enable all the experimental features of libc++?

[gzotti]

I see a good increase in performance with a large solarSystem. However, experimental lib support always sounds a bit scary for "safe and trusted" programs. It has been now built to be not an error if a compiler/library does not support std::execution::par, so I have no clear opinion on that. I understand only CLang/FreeBSD is affected? Maybe enable behind yet another CMake flag for this platform, and instruct users with problems to self-compile? (Any estimate of affected users on this platform?)

[alex-w]

Oops, I forget convert this PR to draft, sorry.

This is an experimental PR and in theory these changes affected FreeBSD and macOS. Of course we have very limited number of FreeBSD users and it looks as not critical changes for this platform. The number of macOS users are more than FreeBSD users, but AppleClang has some specifics and the latest release of AppleClang has version 16.0 (macOS 15.0 Sequoia), so, this patch is not applicable here. Probably I should add a separate solution for macOS via using oneDPL library.