Fix OpenMP compilation on MacOS

[henrysky]

Currently galpy wheels for MacOS on PyPI are not compiled with OpenMP because -fopenmp is not supported by default clang in the OS but need to use -Xclang=-fopenmp. This PR provides a fix such that galpy can use OpenMP on MacOS too, also removes unneccessary code to define inline for Windows that use distutils which was removed in Python 3.12.

A quick sanity check with nm -g libgalpy.cpython-312-darwin.so using a galpy wheel on PyPI indeed show OpenMP is not used (missing symbols like _omp_get_max_threads since v1.8.1).

In setup.py, I have assumed homebrew is used and set the ibclude/lib path directly. Not sure what is the best way to do this since openmp does not have something like gsl-config --prefix.

The performance test is as follow

[codecov[bot]]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 99.91%. Comparing base (29a9992) to head (2342400). Report is 28 commits behind head on main.

Additional details and impacted files

```diff @@ Coverage Diff @@ ## main #651 +/- ## ======================================= Coverage 99.91% 99.91% ======================================= Files 200 200 Lines 29260 29260 Branches 564 563 -1 ======================================= Hits 29236 29236 Misses 24 24 ```

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

[jobovy]

Thanks for this PR! We need to move carefully here though, because it seems like there are still issues with using OpenMP on a Mac with the wheels. I had actually just tried adding OpenMP support in #649, but testing that now it seems like it (a) doesn't actually use multiple CPUs and (b) has issues with loading the library.

Overall this seems to work, but there's a weird bug currently when you install numpy (I think) using conda and then pip install this wheel. Importing galpy.orbit then leads to

OMP: Error #15: Initializing libomp.dylib, but found libomp.dylib already initialized.
OMP: Hint This means that multiple copies of the OpenMP runtime have been linked into the program. That is dangerous, since it can degrade performance or cause incorrect results. The best thing to do is to ensure that only a single OpenMP runtime is linked into the process, e.g. by avoiding static linking of the OpenMP runtime in any library. As an unsafe, unsupported, undocumented workaround you can set the environment variable KMP_DUPLICATE_LIB_OK=TRUE to allow the program to continue to execute, but that may cause crashes or silently produce incorrect results. For more information, please see http://openmp.llvm.org/
Abort trap: 6

This doesn't happen when you pip install numpy instead, so it's some weird library conflict that happens with conda.

In the meantime, if the Windows inline stuff isn't necessary anymore, could you split that off in a separate PR? That way this one can be more focused on Mac OpenMP support (which may not necessarily land).

[jobovy]

Superseded by #660.