FASTSim 2.1.0

[kylecarow]

@calbaker This should be ready for review

I've modified the workflows so that the wheel files are built and tested, then when all runs in the matrix complete, a separate job uploads them to PyPI. I've kept the vX.X.X format as the trigger, rather than rX.X.X. I have not tested the twine portion of this, but it uses the same uploading instructions as the original release.yaml does, so I imagine it should work.

Some next steps:

• review the changes to the files, especially the workflows
• if tests pass, approve & merge this PR
• tag the merge commit with v2.1.0 and watch release.yaml go to work!

[kylecarow]

@calbaker BTW, it looks like tagging the merge commit could probably done with an action as well. We could probably have the trigger be when a PR with vX.X.X in the title and/or a release label is merged.

[kylecarow]

@calbaker I've readded wheels.yaml, and changed its trigger to workflow_dispatch. Like we discussed last week, this only allows it to be run from github.com on the default branch. However, if you download the GitHub CLI, you can run it manually on non-default branches as well.

Set up GitHub CLI with:
brew install gh
gh auth login

Then run the workflow, e.g. on branch fastsim-2.1.0:
gh workflow run wheels -r fastsim-2.1.0

Does this sound ok to you? The wheels are still built and tested in release.yaml before anything is published to PyPI.

[calbaker]

@kylecarow , I'm thinking I like the solution Nick came up with in ALTRIOS:
/~https://github.com/NREL/altrios-private/blob/cf47f12f24589ad01a3f71dba4c0af272be6c12e/.github/workflows/wheels.yaml#L5