Make "Bump etcd Version in Kubernetes" part of the etcd's release process

### What would you like to be added?

sig-etcd owns the task of bumping etcd version in Kubernetes, and we also have an [step by step guide](https://github.com/etcd-io/etcd/blob/main/Documentation/contributor-guide/bump_etcd_version_k8s.md) on how to do this (Thanks @joshjms ).

I think we should make the task part of the etcd's release process, so that it won't be forgotten or significant delayed. The concern for now is that if there is any regression, it may affect all the end users who use kubeadm to install K8s cluster. But it might not be a big problem, because the etcd version should have already been verified in Kubernetes workflow checks when it being bumped, i.e. https://github.com/kubernetes/kubernetes/pull/131144. Nonetheless, it still needs some soak time (i.e. 2 ~ 3 weeks); but we might want to bump the etcd image immediately if there are some major CVEs.

So after we release each patch, the proposed high level process is something like below,
- build & publish the etcd image;
- bump etcd image (i.e. https://github.com/kubernetes/kubernetes/pull/131144).
- If there are some major CVE fixes, we just merge the PR (of course after all workflows green);
- otherwise, we need to wait for some soak time (i.e. 2 ~ 3 weeks) before merging it.
- bump etcd client sdk

If the patch contains major bug fixes or CVE fixes, we should bump the etcd version for all K8s supported versions, from higher to lower version.

Also as mentioned in https://github.com/etcd-io/etcd/pull/19717#issuecomment-2789183940, we bump etcd v3.5.x for K8s release-1.33 and lower versions, and bump etcd v3.6.x for release-1.34 (master for now) and higher versions.

cc @fuweid @serathius @liggitt @neolit123 @ivanvc @jmhbnz @joshjms @henrybear327

### Why is this needed?

to have a smooth integration etcd with Kubernetes

Start with Documentation/contributor-guide/bump_etcd_version_k8s.md and the linked Kubernetes pull request to understand the current bump steps and verification. Then inspect the existing etcd release process and determine how image publication, Kubernetes version bumps, soak time or CVE exceptions, and client SDK bumps should be incorporated; done means the process is documented and executable for supported Kubernetes versions.

Written by the indexing model from the issue text.