Group CI jobs into function-specific workflows

[mflendrich]

There's a number of problems with the current CI layout:

• tightly coupled to the idea of only one released artifact - the 1.x monolith. There are two reasons to change that: a) we need to release 2.x as well which is a separate executable, b) it's not impossible that we'll have more artifacts in the future if we modularize KIC further
• not possible to release 1.x and 2.x from the same build (consequence of the above, very important)
• not obvious from the failed job/workflow name what has failed

The spirit of this change is to organize the CI implementation with the following proposed way (not set in stone - it's just a proposal):

Workflow: common

• static analysis (lint, license checks, etc.)
• unit tests

Workflow: KIC 1.x test

• old integration test for KIC 1.x (unless KIC 2.0 - Move RG tests to root dir #1337 gets followed up on before)
• new integration test

Workflow: KIC 2.x test

• new integration test

Workflow: KIC 1.x release

• push the head of the branch to a tag with the branch name (needs to be distinguished from the KIC 2.x build from the same commit)
• if tagged with semver: push the semver tag

Workflow: KIC 2.x release

• push the head of the branch to a tag with the branch name (needs to be distinguished from the KIC 1.x build from the same commit)
• if tagged with semver: push the semver tag

Acceptance criteria:

• structure of CI workflows/jobs as above (feel free to propose a better one)
• all the checkboxes above either completed, or (if not implemented yet and impractical to implement as part of this effort) having corresponding issues created in the "Continuous Integration" milestone

[rainest]

Some other thoughts while reviewing the workflows: does it make sense to reorganize the common test jobs somewhat? Currently we have two, both of which install Go, cache modules, and check out the repo to set up the environment. From there:

• Job A installs and runs golangci-lint, verifies codegen, and verifies manifests.
• Job B job runs unit tests, generates code coverage, and uploads coverage to Codecov. It also installs golint but it's not clear if it needs it.

None of the non-setup steps in Job A depend on any of the others, and could run in parallel. I'm not 100% sure on action efficiency stuff, but it seems like we could have:

• Environment job to handle the common install Go, cache modules, check out repo steps.
• Lint job
• Verify manifest job
• Verify codegen job
• Unit and Codecov job

All jobs require the environment job (other than the environment job itself). That should run a bit faster, correct? Any reason we should instead keep the current organization?

[rainest]

Implemented in #1410 and #1409, though the latter is currently busted because our token secrets aren't correct. Work on that is ongoing outside of PRs.