Fix/downstream linking

[SimonPinches]

Fix linking for downstream projects here, rather than in every package that builds on IMAS-Core: they no longer need to strip unsupported linker flags from al-core.pc, or install Boost to use the al-core CMake package.

Changes

• al-core.pc: emit -Wl,-rpath only on non-Windows platforms. Windows has no runtime search path (DLLs are found through PATH), and MSVC/lld-link rejects -rpath. This completes Drop --defsym in al-core.pc when not accepted #84, which did the same for --defsym (not yet in a release).
• al-coreConfig.cmake: remove find_dependency(Boost COMPONENTS filesystem). libal is always a shared library that links Boost PRIVATE, so the exported al-core::al target never references Boost and consumers don't need it.

Why

1. GNU-ld-only flags in al-core.pc: Apple's ld64 rejects --defsym, and the Windows linker rejects both --defsym and -rpath. Downstream builds currently strip them by hand:

• conda-forge imas-fortran feedstock, macOS: build.sh L55-62
• IMAS-Fortran win-64 conda build (in progress): bld.bat L42-49. Without it, pkg_check_modules(al-core) produces link options the Windows linker rejects.

2. find_dependency(Boost) breaks find_package(al-core):

• in conda environments: the runtime libboost package ships no Boost CMake config (only libboost-devel does);
• in Fortran-only projects, even when Boost is installed: Boost's package config fails with a hard error in BoostDetectToolset when no C++ compiler is enabled. Reproduced with the IMAS-Core 5.7.1 module on SDCC via find_package(al-fortran) (IMAS-Fortran's new CMake package config).

CI

The macosx_arm64 wheel failures are pre-existing on develop: Homebrew now ships OpenSSL 4.0, which breaks the -Werror build of UDA. They are fixed separately in #90, with the upstream UDA fix in ukaea/UDA#144.

[olivhoenen]

Fix linking here rather than in all HLIs. I.e. HLIs don't have to strip unnecessary linking arguments.

Could you point to issue/comment that explains the need for such fix, for proper ref?

[SimonPinches]

Fix linking here rather than in all HLIs. I.e. HLIs don't have to strip unnecessary linking arguments.

Could you point to issue/comment that explains the need for such fix, for proper ref?

Good point. I've expanded the PR description with references to the downstream workarounds this replaces.

[olivhoenen]

LGTM