Drop --defsym in al-core.pc when not accepted

[SimonPinches]

The Libs line of al-core.pc unconditionally contains '-Wl,--defsym,AL_VER_<version>=0', which stamps the Access Layer version into consuming binaries as a linker-defined symbol. --defsym is specific to GNU-compatible linkers: Apple's ld64 fails with 'ld: unknown option: --defsym' and MSVC's link.exe rejects it too, so any consumer linking against al-core via pkg-config on macOS fails. (First observed building the conda-forge imas-cpp/-fortran/-java packages for osx-64.)

Make the flag a configure-time substitution that is emitted only on platforms with a GNU-compatible linker. The generated al-core.pc is unchanged on Linux.

[SimonPinches]

If we want keep stamping the IMAS-Core and HLI versions into the library binaries, a better mechanism would be to move it from the link line into a public header that every consumer compiles, e.g. in ALDef.h:

  /* retained in every object that includes this header */
  static const char AL_VERSION_IDENT[] __attribute__((used)) = "AL_VER=5.7.2";

with an MSVC branch using #pragma comment(user, "AL_VER=5.7.2") — and on MSVC you can even upgrade the stamp to an enforcement: #pragma detect_mismatch("AL_VER", "5.7.2") makes the linker error out if two objects were compiled against different AL versions, which is strictly stronger than the current symbol. Retrieval becomes strings binary | grep AL_VER= on every platform instead of nm | grep AL_VER_. The trade-offs: the ident lands in every object (a few bytes each), and it stamps compile-time rather than link-time consumers — semantically what you usually want anyway.

With this approach we could track IMAS-Core, IMAS-HLI versions simultaneously at little cost. Not sure if we need to, but if we did....