Move build system to cmake

[Yurlungur]

PR Summary

In this PR, I move the build system to cmake. I do so mainly to make spiner more consistent with, e.g., the best-practices we've built up in singularity-eos. In practice, this means the following changes:

• The Makefiles in test have been removed
• I reorganize the directory structure to contain a spiner subdirectory, just for better code organization. This also let's me make an install target for spiner, as well as modify the include paths to be #include <spiner/filename.hpp>.
• Catch2 is now dynamically fetched. The submodule has been removed.
• Kokkos and Cuda must be treated appropriately in CMakeLists.txt, which I have attempted to do. There are some gotchas. I found it wouldn't build if I installed the default spack variant of Kokkos. I needed kokkos~shared.
• Formatting has been enabled. You can now type make format in the build directory to auto-format the code. I did so, which means there are significant diffs to some files. In particular ports-of-call/portability.hpp, ports-of-call/portable-arrays.hpp, and spiner/databox.hpp all have been autoformatted, but had no meaningful changes otherwise. @chadmeyer please let me know if this is a problem for the ports-of-call files. It can be undone.
• I added a github workflow to check formatting.

My hope is this will make it easier to integrate spiner with spack, with our CI, and with the singularity-eos build system we've constructed. That said, I could be wrong on this. I was disappointed to find that the new CMakeLists.txt are like 3x times more lines than the old Makefiles, which makes me wonder. It's also a breaking change with downstream, since the directory structure changed. (Of course, the downstream fixes should be straightforward.)

Due to my uncertainty, I've marked this as WIP until I can get input from stakeholders, in particular, I'm hoping to hear from at least a few of:

• @ktsai7 and @mauneyc-LANL who have been messing with the build system and CI
• @chadmeyer , @jdolence , and @brryan who are stakeholders in downstream codes
• @dholladay00 who has done a lot of work on both spiner and singularity-eos

Please take a look and let me know what you think.

PR Checklist

• [x] Code is formatted.
• [x] Adds a test for any bugs fixed. Adds tests for new features.

[Yurlungur]

Another consideration: My current draft does not support "in-tree" Kokkos builds of the spiner tests. However, if Kokkos is being built in-tree in a larger project, then that still works. Is there a desire to support "in-tree" builds for the tests?

[Yurlungur]

I also took this as an opportunity to invite @jhp-lanl and @mauneyc-LANL to the repo.

[Yurlungur]

Another suggestion by @mauneyc-LANL : Add a spiner::spiner target, which includes the spiner::flags and spiner::libs targets.

[Yurlungur]

With @mauneyc-LANL 's suggestions, I'm removing the WIP. I will merge once I've implemented them, if I don't hear from anyone else.

[Yurlungur]

With two approvals and tests passing, I'm going to merge this. That said, @dholladay00 I am interested in your thoughts. If you get the chance to look, let me know what you think.

[dholladay00]

took a brief look and everything looked ok to me. currently do we install this (when installing singularity-eos) just by copying headers, did you test if installation behavior needed to change @Yurlungur ?

[Yurlungur]

took a brief look and everything looked ok to me. currently do we install this (when installing singularity-eos) just by copying headers, did you test if installation behavior needed to change @Yurlungur ?

Thanks, @dholladay00 ! In singularity-eos, yes, all we do is copy the headers. I didn't change the cmake build system for singularity-eos to reflect the changes in spiner. What will need to change is we'll need to add spiner as a subdirectory, but then things should just work (I hope).