ci: Setup automated python-semantic-release action

[hcallahan-lowrisc]

Ignore final commit, used for testing and included for reference only during review.

Expand the the release.yml workflow to cut new dvsim releases using python-semantic-release if a merged pull request contains commits that follow the configured conventional-commit formatting.

• Action triggered upon PR merge to master
• New release cut if new commits contain conventional-commit directives that increment the Maj:Min:Pat versions.
• Add a commit incrementing the version, including changelog updates for updates since the previous release, and tagged with release version
• Gets a token for the lowrisc-ci app to push to master, overriding the normal branch protection rules
• Build dist, and push src + dist to a new Github Release
• Run deployment job(s) to deploy dist to PyPi (and test.PyPi)

Some examples from deployments on my personal fork

• Pull Request cutting a new patch release, triggering the test.pypi deployment
• release.yml workflow for the above PR.
• Alternate run of workflow which did not trigger a new release due to no actionable conventional commit messages
• test.pypi releases created by the action
• Github Release for 1.0.0 showing the changelog since the only previous release (0.1.0)

There is still some TODOs here, and I would appreciate some reviews as GHA is not something I am extremely confident about, but it's definitely ready for review.

Opens:

• How do multiple in-flight merges in close sucession behave? There is a 'concurrency' attribute in the first job, but I'm not sure if this is sufficient. Also, how might we test for issues here?

Todo:

• Enable merge queues
• Add branch protection exception for lowrisc-ci app
• Setup pypi/test.pypi / repo environments for Trusted Publishing flows.
  • pypi
  • test.pypi

Also follow-up opens in my mind:

• User Documentation, Commit Lints, PR Templates
• Maintainer Documentation, testing releases, cutting releases locally, Act for action testing.

After this is merged, I suggest we use it to cut a 1.0.0 release :)

Closes #5

[machshev]

Great work @hcallahan-lowrisc!

As you say it looks like concurrency could be an issue, the docs are not clear on what the actual behaviour is. But it looks like concurrency groups only support one waiting workflow/job. So if a 3rd PRs get merged before the first release workflow is finished then the 2nd workflow is killed.

If we reduce the concurrency group scope to just the job that calculates the release version number (which is a lot quicker than the full workflow), then this could mitigate such an issue.

[hcallahan-lowrisc]

This is now ready for review/approval, though please do not merge as I need to setup the repo configuration beforehand (TODOs), and ensure the CA will correctly issue a token.

[machshev]

LGTM