Improve release workflows

[jbeaurivage]

Summary

The release workflows have been somewhat broken for the past few releases, requiring manual intervention and adding fricition to the release process (and thus, we're motivated to release less often). Also, since we took the decision to only bump Tier 1s using the bump-crates workflow, the only way to bump Tier 2 BSPs is by doing so manually.

Publishing crates is unaffected as long as the versions are bumped beforehand.

This PR tries to fix the workflows, and adds more automation:

• Bumping PACs, BSPs and the HAL create a new PR, but doesn't try to publish anything to crates.io
• Bumping a crate also updates its changelog version
• Releasing the HAL adds a git tag to the repo
• Tier 2 BSP version bumps are automated with their own workflow

Finally, also revert the PAC changelogs to the format expected by the workflows.

What's new

• The option to sync dependencies for PACs and the HAL in Tier BSPs is removed. The HAL, Tier 1 BSPs and PACs should always remain in sync.
• The HAL, Tier 1 BSPs, and PACS share a unified version bump workflow. Tier 2 BSPs have their own version bump workflow. Maintainers who merge an update to a Tier 2 BSP are expected to immediately bump the BSPs's version and release it. There is no reason to wait for a new HAL release before releasing Tier 2 BSPs. This also has the advantage that we don't need to try to remember when the BSP was last released.
• Releasing the HAL adds a v${version} tag to the repo

Unfortunately, some of the workflows will have to remain untested until this PR is merged as they will only get picked up by GHA when on master.

[ianrrees]

As discussed in chat, it might be a bit tidier to replace the Python script that gets the crate version with cargo metadata --no-deps --format-version 1 | jq '.packages[0].version', and I guess have the script that updates the changelog take the new version as an argument

[jbeaurivage]

As discussed in chat, it might be a bit tidier to replace the Python script that gets the crate version with cargo metadata --no-deps --format-version 1 | jq '.packages[0].version', and I guess have the script that updates the changelog take the new version as an argument

@ianrrees Should be all good to go now!

[ianrrees]

The CI got stuck building one of the T2 BSPs, @jbeaurivage and I decided to just squash and merge anyway as it's highly unlikely these changes were the source of the CI issue.