ci: Use semantic release development workflow

[markmetcalfe]

Having to manually make releases seems somewhat arbitrary given that a lot of the changes are often unrelated, and desired by different teams. Wanting to remove the amount of effort to make and release changes, and make it so it's more decentralised so individual teams can make changes without having to involve others/wait for the next manual release (of which we don't really have a schedule for)

I’m proposing that we switch from the current release model (of merging into develop, then merging into master and manually creating a release) to a model where:

1. Commits are named using the conventional commit format (i.e. feat/fix/chore)
2. PRs require 2 approvals rather than 1 (the idea being one Mac tester and one WSL tester)
3. PRs are merged directly into master
4. Releases are made automatically once a PR is merged (using the semantic release process)

This then creates a release that looks like this (in my personal fork) that uses the conventional commit message to determine whether to increment the minor or patch version, and uses it to autogenerate release notes.

[jakub-krauz-totara]

Continuous delivery for the win! Great move imo.