🌱 DNM: Add KAL linter for linting API conventions

[JoelSpeed]

What this PR does / why we need it:

This PR adds KAL to the linter workflows to lint API conventions.

The linter is a WIP project that I have been working on and the focus of the project is to try and enforce API conventions via a linter, to take off some of the cognitive load of API review.

At the moment, there are 10 sub-linters implemented, each of which I've listed out within the configuration with a description of what they mean.

We should discuss each one and agree upon them, and then, the intention is that we can use this linter for the new v1beta2 types.

The set up here runs KAL separately from the main golangci-lint run, so that the GitHub workflow for linting can continue to use the official GH action, which has some caching and speed improvements over running the binary manually.

The config for KAL is set to run only on files containing api/v1beta2 in the name. Since we don't have any of those yet, I've temporarily added api/v1beta1 so that we can see what the output might look like. We will want to remove that before merging.

I've also updated GolangCI-Lint to v1.63.4. v1.63 introduced the ability for custom linters to apply fixes to the code, so lint-fix will work with KAL as well provided we use a v1.63 or later version. I figured it best to update the main version of the linter at the same time.

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #

[k8s-ci-robot]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign sbueringer for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[JoelSpeed]

In theory we could add --new-from-rev=main to allow this to lint only changes since the main branch, which would allow us to start enforcing the linting rules for new changes to older APIs as well 🤔

[nrb]

If I'm understanding correctly, if/when the project's accepted in kubernetes-sigs, this file is the only thing that needs to change, correct?

[JoelSpeed]

Yep, we would need to update this to point to the new source. There may of course be other changes over time since this project is early in development, but, I would hope that we can keep this fairly compatible with what we are doing here and now

My aim at least is that it stays as a golangci-lint plugin until and unless it replaces the flexibility of the configuration already implemented by golangci-lint. But there's an awful lot of functionality there and I don't see much value in re-implementing that.

[nrb]

/area api