Add Nextflow configuration regression tests

[nwiltsie]

Description

This PR adds in the new Nextflow configuration regression test Action from uclahs-cds/tool-Nextflow-action#16, as well as two regression tests. (This is the formal version of #52.)

I specifically make no claims that the values shown in the tests are what we intend - I only claim that they match the current outputs of the configuration process.

Testing Results

As these are infrastructure-only changes, there are no changes to the pipeline itself and thus no need to run other tests.

Checklist

• I have read the code review guidelines and the code review best practice on GitHub check-list.

• I have reviewed the Nextflow pipeline standards.

• The name of the branch is meaningful and well formatted following the standards, using [AD_username (or 5 letters of AD if AD is too long)]-[brief_description_of_branch].

• I have set up or verified the branch protection rule following the github standards before opening this pull request.

• I have added my name to the contributors listings in the manifest block in the nextflow.config as part of this pull request, am listed
  already, or do not wish to be listed. (This acknowledgement is optional.)

• I have added the changes included in this pull request to the CHANGELOG.md under the next release version or unreleased, and updated the date.

• I have updated the version number in the metadata.yaml and manifest block of the nextflow.config file following semver, or the version number has already been updated. (Leave it unchecked if you are unsure about new version number and discuss it with the infrastructure team in this PR.)

• I have tested the pipeline using NFTest, or I have justified why I did not need to run NFTest above.

[yashpatel6]

It may be worth making the regression test(s) a required passing check before merging PRs similar to how we have CI/CD set

[nwiltsie]

It may be worth making the regression test(s) a required passing check before merging PRs similar to how we have CI/CD set

Yeah, we'll need to work out the best way of doing that - the job names are somewhat dynamic, as they match the test files on disk, so tracking all of them is a moving target. Maybe we can add a summary "all tests passed" check to the Action and then depend upon that.