Update cmake configuration

[Yaswant Pradhan (yaswant)]

PR Summary

This change finishes the CMake install parity work so downstream consumers (e.g., Mule) get the same critical install artifacts expected from the legacy build flow.

Code Reviewer: Sam Clarke-Green (@t00sa)

What's changed

1. Added installation of standalone shared libraries for key subcomponents:
   • libshum_constants.so
   • libshum_string_conv.so
   • libshum_wgdos_packing.so
   • libshum_byteswap.so
   • libshum_spiral_search.so
2. Added installation of missing public headers:
   • shumlib_version.h
   • c_shum_wgdos_packing_version.h
3. Optionally, added generation of the WGDOS version compatibility header from a template, and ensured it defines SHUMLIB_VERSION for external consumers before including shumlib_version.h.
4. Added install-time symlink creation so the install prefix contains:
   • lib64 directory for libraries
   • lib symlink pointing to lib64
5. Fixed source/include path handling for new sub-library CMake targets to use project-root-qualified paths, preventing missing-source errors during configure/build.

This keeps the existing aggregate library behaviour while adding/installing the required standalone targets and compatibility headers needed by downstream users.

I'll add an example wrapper script in MetOffice/mule in a separate Mule PR.

Checks

• Configure/build/install succeeds with CMake.
• Install tree contains the expected five shared libraries in lib64.
• Install tree contains the expected headers in include.
• Prefix contains lib symlink to lib64.

Code Quality Checklist

(Some checks are automatically carried out via the CI pipeline)

• I have performed a self-review of my own code
• My code follows the project's style guidelines
• Comments have been included that aid undertanding and enhance the
  readability of the code
• My changes generate no new warnings

Testing

• I have tested this change locally, using the rose-stem suite
• If any tests fail (rose-stem or CI) the reason is understood and
  acceptable (eg. kgo changes)
• I have added tests to cover new functionality as appropriate (eg. system
  tests, unit tests, etc.)

trac.log

Security Considerations

• This change does not introduce security vulnerabilities
• I have reviewed the code for potential security issues
• Sensitive data is properly handled (if applicable)
• Authentication and authorisation are properly implemented (if applicable)

Performance Impact

• Performance of the code has been considered and, if applicable, suitable
  performance measurements have been conducted

AI Assistance and Attribution

• Some of the content of this change has been produced with the assistance
  of Generative AI tool name (e.g., Met Office Github Copilot Enterprise,
  Github Copilot Personal, ChatGPT GPT-4, etc) and I have followed the
  Simulation Systems AI policy(including attribution labels)

Documentation

• Where appropriate I have updated documentation related to this change and
  confirmed that it builds correctly

Code Review

• All dependencies have been resolved
• Related Issues have been properly linked and addressed
• CLA compliance has been confirmed
• Code quality standards have been met
• Tests are adequate and have passed
• Documentation is complete and accurate
• Security considerations have been addressed
• Performance impact is acceptable

[Yaswant Pradhan (yaswant)]

Trying to compile with Ninja caught some useful issues, e.g.,:

[53/177] Generating Fortran dyndep file shum_constants/src/CMakeFiles/shum_constants.dir/Fortran.dd
ninja: build stopped: multiple rules generate modules/f_shum_chemistry_constants_mod.mod.

This is a classic Ninja dyndep conflict: both shum and shum_constants (and other standalone targets) compile the same .f90 files and write .mod files to the shared modules/ (${CMAKE_Fortran_MODULE_DIRECTORY}) directory, so two rules claim ownership of the same .mod file. Make silently overwrites (so did not catch this in my original changes); Ninja rejects it.

The fix is to give each standalone target its own private Fortran_MODULE_DIRECTORY. Transitive target_link_libraries already propagates each library's module path to dependents (e.g. shum_byteswap -> shum_string_conv), so cross-lib compilation still works correctly.

I think the whole project can be CMake-refactored, once we deprecate the legacy approach.

Additional changes in 25d97c3