feat: qa on merge to master OR using merge_groups with slack notification

[robert-bo-davis]

Primary reviewer:

Description

This PR is an example of two potential patterns for streamlining the trunk QA process if we move away from manual QA tags.

These actions have, obviously, not been tested yet, but should be fairly close to working.

Common Functionality:

1. Create a qa tag based on a version name found in the PR title (ex: a pr with the title v1.2.3 - pre release will produce a qa/v1.2.3 tag.

2. Create a qa tag based on a ticket number found in the PR title. (ex: a pr with the tittle CHI-1234 - some long description will automatically create the tag qa/CHI-1234 when it is merged.

3. There is a scheduled job to cleanup qa tags after 2 weeks.

Differences:

global-qa-merge-group.yml

This action is based on the POC work from https://github.com/techmatters/test-merge-group-action. It uses the new github merge_group trigger to run the tests after the "merge" button is pushed on a PR, but before the merge actually happens. If tests fail, the merge will be rejected and won't make it into the target branch. There are quite a few caveats discussed in the POC repo.

global-qa-push.yml

This action is triggered after any code is merged into master. It can't block failing code from making it into master, so it notifies loudly in #aselo-engineering on any failure.

Verification steps