Add Spack-based CI workflow

[AlexanderRichert-NOAA]

This PR adds a Spack-based CI workflow that builds and tests bufr. The new files are the workflow file itself, Spack.yml, and the Spack package recipe, which should serve as an authoritative copy of the recipe, and should be updated to reflect changes in CMake build options, etc.

Fixes #527

squash-n-merge

[jbathegit]

Thanks @AlexanderRichert-NOAA, and this looks OK to me.

Just to clarify - whenever we do future releases (the next one will likely be v12.1.0 at some point), will we now need to remember to manually add all of the info for that new release (e.g. the new version with its sha256 identifier) to spack/package.py?

[AlexanderRichert-NOAA]

Correct-- Specifically, after the release is done through GitHub, download the tar.gz file, get the sha256sum, and add the new version.

For posterity: When adding new CMake build options, to add the corresponding Spack recipe variant before the new version that will have that build option has been released, you would do something like variant("newopt", when="@develop") so that the new variant is only associated with the updated code, then the @develop can be changed to the actual version number after the release is done and the new version is added to the recipe. Needless to say I can help with this as needed if/when the time comes.

[jbathegit]

Correct-- Specifically, after the release is done through GitHub, download the tar.gz file, get the sha256sum, and add the new version.

Thanks Alex, and I can certainly download the tarfile post-release and do a shasum -a 256 on it to get the hashcode, but then when I go back to add that hashcode into spack/package.py, it will be as a separate post-release commit to the repository and so not part of the actual tar.gz file. I presume that's our intent here and the way it's supposed to work?

[AlexanderRichert-NOAA]

Correct, it'll be the same way for all NCEPLIBS.