Deal with shared lib file not found failures due to OS file extension mismatch

[mattw-nws]

Causes AbstractCLibBmiAdapter.hpp to add the appropriate extension if missing (.so or .dylib) or try the alternative extension, for a library_file if the path provided was not readable. This lets us collapse at least some places in tests that require multiple files/code just to get around this OS difference.

Additions

• Fallback handler in AbstractCLibBmiAdapter.hpp

Removals

Changes

• Removed use of __macos realization file from Run surfacebmi plus cfebmi test... does not delete this realization file... should we?

Testing

1. Test Run surfacebmi plus cfebmi now uses the Linux realization file (with .so extensionless path to dylib file) on macOS and Linux tests and succeeds.

Screenshots

Notes

Todos

Checklist

• PR has an informative and human-readable title
• Changes are limited to a single goal (no scope creep)
• Code can be automatically merged (no conflicts)
• Code follows project standards (link if applicable)
• Passes all existing automated tests
• Any change in functionality is tested
• New functions are documented (with a description, list of inputs, and expected output)
• Placeholder code is flagged / future todos are captured in comments
• Project documentation has been updated (including the "Unreleased" section of the CHANGELOG)
• Reviewers requested with the Reviewers tool ➡️

Testing checklist (automated report can be put here)

Target Environment support

• Linux

[donaldwj]

It is possible that windows compiling with Cygwin or mingw could get here. Would it be worth checking for and warning that Windows is not currently supported?

[mattw-nws]

Possibly... I have a feeling it wouldn't get that far. Maybe we should consider this: https://github.com/cygwin/cygwin-install-action ... someday.