Automate manual steps in release with a repeatable process

Currently release process (RELEASE.md) requires the Release Shepherd to generate deployment manifests and then verify them with tests before uploading them to the GitHub Release.

We could automate possible repeatable sections in this process using a post-submit GitHub Action that triggers when a new version tag is pushed.

Some ideas for exploring:

A scheduled cronjob that -
1. checks the latest VERSION tag available in k8s-registry
2. generate the release manifests
3. run test-e2e with prepared manifests
4. create gh action release (in draft)

This could be further utilized with [krel](https://github.com/kubernetes/release/blob/master/docs/krel/README.md) to add some structure to release automation by auto-generating release notes to a `previous-releases/vX.Y.Z/release-notes.md` target. This could be a `create-new-minor-release.sh` script to make changes to create the release-cut PR. The automation will utilize the metadata for release.

This would reduce the release toil while also ensuring a repeatable controlled process for the nrc releases.

cc @Priyankasaggu11929 we could break it down to subtasks and see how we could create good-first-issues for the project

[ajaysundark] Update: This project is now proposed for LFX mentorship program. Please refrain from self-assigning yourself this feature

Start with RELEASE.md and the krel documentation linked in the issue, then trace the current manifest-generation, test-e2e, and GitHub Release steps. Define which repeatable steps a tag-triggered or scheduled GitHub Action should cover; done means the process is documented and can generate manifests, verify them, and create a draft release with release notes.

Written by the indexing model from the issue text.