Working towards a more reproductible release process

[jbeaurivage]

@ianrrees and I have recently had multiple conversations about the CI/CD pipeline, more specifically about the way we release crates. There are a few things we want to improve. Not everything has to be addressed immediately, but I wanted to document it here before it gets lost in the Matrix sauce.

• The first thing is that we are currently publishing BSPs is in batches. ie, we try to shotgun-publish all BSPs at once, and just ignore the ones which already are published in crates.io. This obviously isn't great. The BSP publishing process should go according to these rules:
  • Tier 1 BSPs should all be published together
  • Since the BSPs reexport atsamd-hal, any release of the HAL should trigger a re-release of the Tier 1 BSPs with the same bump level (patch, minor or major).
  • Tier 2 BSPs should be published individually (or through a user-provided list of crates to publish)
  • Ideally, we'd like to reuse the "publish an individual crate" script and simply pass it a list of BSPs to cover all use cases
• Tier 1 BSPs specify a path dependency. However, their crates.io published counterparts use the crates.io version of the HAL. Therefore we'd like to test build the BSPs against the crates.io atsamd-hal version before publishing them. Turns out this is somewhat tricky as there's no nice way to tell Cargo to ignore path dependencies through CLI options, so we'd need to mess with the crates' Cargo.toml using sed or something similar.

[jbeaurivage]

Closed via #762.