more F90 updates

[jbathegit]

Part of #254
Part of #328

[jbathegit]

So I was about to submit this bundle for review, but we suddenly have an issue with the "Spack / Spack (ubuntu-latest, +python ~shared) (pull_request)" CI test.

I've tried re-running it twice but to no avail. I'm not sure why it's failing all of a sudden, but one thing I did note is that it's trying to download the bufr test files from the emcrzdm server, which isn't available right now b/c of the ongoing recovery from all of the problems NCO had yesterday in their data center. And Spack.yml is apparently the only YAML file which doesn't include the TEST_FILE_DIR option to cmake (along with a key attribute under a "cache-data" option) to instead copy the bufr test files from /home/runner/data rather than trying to download them from emcrzdm every time. So that's one thing that should probably be addressed in Spack.yml.

However, that alone wouldn't explain why the corresponding "Spack / Spack (ubuntu-latest, ~python +shared) (pull_request)" CI test, which is also run out of the same Spack.yml workflow, is still working fine even though emcrzdm isn't currently available. So something else must be going on here.

@AlexanderRichert-NOAA @edwardhartnett any thoughts?

[AlexanderRichert-NOAA]

The Python unit tests are failing with Failed to change working directory to /tmp/runner/spack-stage/spack-stage-bufr-develop-zeuqln3tiwikb7hge2x4q6z6ur2w7g3u/spack-build-zeuqln3/test/testfiles : No such file or directory which might suggest it's related to the test files. I'll make a test PR where I'll see if I can use the existing cached test files and see if that does the trick. And I agree the Spack workflow should include the cache usage.

[jbathegit]

Thanks again Alex for your work in #588 to fix the above Spack CI issue!