Follow up on consume GitHub Releases

[javirln]

This is a follow up of the issue #785. The current status at the time of writing is the following:

• There is a reusable workflow on Chainloop labs: https://github.com/chainloop-dev/labs/blob/main/.github/workflows/chainloop_github_release.yml
• The workflow have some set of constraints to only run if whatever triggered them was a release event and type published
• The issue with the current approach is this a GitHub token cannot trigger another workflow. This means that for the Chainloops' approach it does not work since we are triggering a release using goreleaser that uses a GITHUB_TOKEN.

The goals of the task are:

• Continue the discussions started on Consume GitHub releases #785
• Reach a consensus on how do we want to allow the use of the workflow (workflow_dispatch, for example)
• Update the documentation accordingly: https://docs.chainloop.dev/guides/github-releases
• Adapt Chainloop's CI with the agreed configuration to be able to use GitHub Releases workflow.

[javirln]

After a discussion offline, we have agreed on the following:

• Remove the release trigger on the reusable workflow and leave it as a plain one
• Add the following inputs:
  • tag: required, which would be actual tag being released.
  • workflow-name, required: Name of the workflow being attested.
  • chainloop-token, required: Token to perform the the attestation.
  • skip-release-notes, optional. This field will indicate the release notes shall be updated with the attestation's link.

No implicit permissions are added to the reusable workflow, developers needs to pass the contents: write, if they want release notes to be updated.

Additionally, this workflow will be added as an additional step for Chainloop's build and package repository.