Semantic Versioning for BACK Stack Releases

We should implement a workflow for semantic versioning of the BACK stack components to clarify the differences between releases and targets for end users.

Suggested workflow:
- Changes to the `main` branch result in a new release candidate for the next semantic minor version.
- The current version is `0.1.0`, so changing the main branch will result in the `0.2.0-rc.1` tag. The next change will result in `0.2.0-rc.2`, and so on.
- Once ready, we will cut a new release (manually trigger for now).
- So if `0.2.0-rc.2` is the current release candidate, we will release `0.2.0`.

This should be (relatively) simple to implement with a GitHub workflow. The existing [`release` workflow](https://github.com/back-stack/showcase/blob/main/.github/workflows/release.yaml) cuts a new tag with the commit sha for each push to the `main` branch. This should be modified so that the `release` workflow handles generated the new version tag and then build steps are moved to a new `build` workflow that is triggered by the creation of a new tag.

Inizia da .github/workflows/release.yaml e verifica come i push su main creino attualmente tag commit-SHA e invochino i passaggi di build. Separa i passaggi di build in un nuovo workflow di build attivato dalla creazione di un tag, quindi verifica che main produca tag release-candidate sequenziali con versione semantica e che la release manuale produca il tag finale corrispondente.

Scritto dal modello di indicizzazione a partire dal testo della issue.