Fix macOS install issue

[liaboveall]

Fix macOS install failure (MH_BUNDLE vs MH_DYLIB)

This PR fixes the macOS CI failure during “Install package verbosely” where linking the Pyfhel extension failed due to an incorrect Mach-O file type for the Afhel library.

• Error observed:
  • ld: unsupported mach-o filetype (only MH_OBJECT and MH_DYLIB can be linked) in '.../libAfhel.dylib'
• Affected jobs:
  • macOS + Python 3.12 / 3.13

Root cause

• On macOS, distutils/setuptools defaults to -bundle for “shared” builds, which produces an MH_BUNDLE, not an MH_DYLIB.
• We then attempt to link libAfhel.dylib as if it were a real dynamic library; the linker rejects MH_BUNDLE inputs for this step, causing the failure.

Changes

Scope: macOS-only. Linux and Windows builds remain unchanged.

• File: setup.py
  • Function: SuperBuildClib.build_shared_lib
  • Changes:
    • Use the existing “mocked CMake” build path for Darwin (macOS), same as for Windows, to build Afhel as a proper SHARED library (i.e., MH_DYLIB).
    • For Darwin, append -Wl,-install_name,@loader_path/<lib_file> to ensure the dylib is loadable at runtime from the extension’s directory.
    • Retain the old Darwin fallback logic that swaps -bundle to -dynamiclib, but this path is no longer taken (kept as a safety net).

Why this works:

• CMake’s add_library(<name> SHARED ...) reliably produces MH_DYLIB on macOS.
• The explicit install_name guarantees the extension can load libAfhel.dylib via @loader_path.

Validation & compatibility

• Static checks: no syntax errors in setup.py or pyproject.toml.
• Linux: unchanged behavior.
• Windows: unchanged behavior (already using the CMake path).
• macOS: Afhel now builds as MH_DYLIB; the subsequent link step for Pyfhel succeeds.

[ibarrond]

Amazing! Thanks a lot!