Use dynamic symbol resolution for libmpi_caf on macOS

[zbeekman]

I'd like to get the CI system back up to parity with the old Travis-CI system. If I have time I'll add this to this PR, otherwise I'll change this from a draft to a real PR and just commit what's here.

Unfortunately mpi_caf.c now calls into libgfortran for the random seed functionality. It would be nice to avoid this if possible, but it's stateful so I doubt that it would be possible. Any code that links to the library should be Fortran code and/or pull in libgfortran.

coverage on master

Summary of changes

On macOS link the caf_mpi shared dylib so that symbols from libgfortran that are unresolved when building the library can be dynamically resolved at runtime (or when the executable is linked, perhaps?).

Rationale for changes

Recent changes broke OpenCoarrays on macOS. These changes were made to handle RNG seeding behavior and support make calls directly into libgfortran. Since this is stateful I doubt there is any way to avoid this, but if there is we should consider it. By default, macOS doesn't like unresolved symbols when creating shared/dynamic .dylib libraries, but you can tell the macOS linker to ignore undefined symbols and resolve them dynamically (at runtime or link time of the executable I presume). On linux the linker doesn't seem to care about creating shared libraries with undefined symbols which is why this issue didn't affect linux.

Additional info and certifications

This pull request (PR) is a:

• [X] Bug fix
• [ ] Feature addition
• [ ] Other, Please describe:

I certify that

• [X] I certify that:
  • I have reviewed and followed the contributing guidelines
  • I will wait at least 24 hours before self-approving the PR to give another OpenCoarrays developer a chance to review my proposed code
  • I have not introduced errant white space (no trailing white space or white space errors may be introduced)
  • I have added an explanation of what these changes do and why they should be included
  • I have checked to ensure there aren't other open Pull Requests for the same change
  • I have you written new tests for these changes
  • I have successfully tested these changes locally
  • I have commented any non-trivial, non-obvious code changes
  • The commits are logically atomic, self consistent and coherent
  • The commit messages follow best practices
  • Test coverage is maintained or increased after this is merged

Code coverage data

[zbeekman]

I don't know what else could be done, besides replicating the code from the gfortran library and thus creating a maintenance nightmare. So when this works, go for it!

Yes, I completely agree. Because it's stateful I don't think there's any other option.

It seems like there are a few small functions copied over from the single image implementation in libgfortran--I wonder if we should remove those, declare extern interfaces and pick them up from libgfortran so we're not duplicating and maintaining that code... Maybe a discussion for another time...