Add simple 'checks' workflow for PR and Merge events

[seanconroy2021]

This workflow automates the following tasks:

1. On pull requests to the 'main' branch, it runs a basic CI check.

2. On pushes or merges to the 'main' branch, it runs the CI check. If successful, it triggers the 'release' job, which performs the following actions:

   • Deletes the 'latest' release and its associated tag.
   • Determines the current version (e.g., v1.0.1) and increments it to create a new version (e.g., v1.0.2).
   • Creates a new version release with the updated tag (e.g., v1.0.2).
   • Create or updates the 'latest' EC Validate Release resolves: HACBS-2725

[lcarva]

Do we need a "latest" release? Can it just be inferred from the release with the highest version? Someone could always use @main if they want. I guess latest is a little bit better, since it's gated by testing. But I don't really like that there's a window where the "latest" release disappears. This would break users.

Suggestion: Just stick to semver for releases.

[seanconroy2021]

@lcarva Thanks for the review. I have fixed the problems 👍🏻

[simonbaird]

Let's explain more clearly in comments why this is commented out.

[seanconroy2021]

Done hopefully more clear now 👍🏻

[lcarva]

I wonder if this change fixed it: enterprise-contract/golden-container#129

As a side note. Usually, a comment like this would go as the first line of the commented out block so it is obvious to the reader, e.g.:

    # FIXME Commented out because ...
    # - name : Run EC Validate (Long_Lived)
    #   uses: ./
    #   with:

[seanconroy2021]

It is now a warning I am going try fix it. I think we will leave it commented out for time being

 warnings:
  - metadata:
      code: slsa_source_correlated.source_code_reference_provided
    msg: Expected source code reference was not provided for verification

[lcarva]

Let's merge this so we can see it in action and address any wrinkles later.