Github action/workflow cleanup and refactor

[hellkite500]

To better manage the expansion of unit and integration tests, a cleanup of the CI workflows and actions was required.

Additions

• An ngen-build composite action
• An ngen-submod-build composite action
• A clean-build composite action

Changes

• Refactor tests to reuse the composite actions, parametrize appropriately based on runner/strategy

Testing

1. All actions tested on my fork

Todos

• Clean up caching???

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 ➡️

Target Environment support

• GitHub CI

[christophertubbs]

It would be cool to see some more centralized walkthrough documentation at some point describing what the workflows are doing from a terminal standpoint. I think those are the best examples of how to work with NGen that anyone could ever come up with. I know to look at the workflows and how to interpret them, but I doubt that's common knowledge.

Super low priority, though.

[ZacharyWills]

I’m with Chris on this, but would rather just automatically generate some documentation from the workflows for building and running an NGEN formulation.

The reason being that ultimately there’s a ton of flexibility in the framework and for testing purposes obviously coverage matters, so for testing I might want to take the scenic route and then once I have made some selections and I have my area of interest I might want a fast lane that just builds my selected parts and runs them.

Ultimately the complexity of running it minimally is low, but getting the model you want, and then making sure it can be reproducible/validated adds complexity and I think we should address that when we can.

[mattw-nws]

In this category of helpful pseudo-docs is the .gitpod.yml I put in in #398... that one builds everything in extern with everything turned on but MPI... it's occurred to me it would be nice to produce multiple versions of that file for different scenarios as @ZacharyWills discussed, but that doesn't seem to be something directly supported by GItpod. It's also occurred to me that the info in that file is somewhat redundant/overlapping with what's in the workflow runners, but I'm not sure how we'd consolidate the two.