Support testing for multiple kubernetes versions

Feature Request

Enforce tests for TiDB operator for the three most recent k8s minor versions.

Is your feature request related to a problem? Please describe:

Currently, the k8s version for e2e is effectively pinned to v1.18.2:
https://github.com/pingcap/tidb-operator/blob/89faa4d976e070543d349d14637cacae073248d7/hack/e2e.sh#L204
We need to test TiDB operator against more recent k8s versions and give a clear commitment on which k8s versions the operator is tested so people won't get surprised running the operator of specific versions on tested k8s versions.

Describe the feature you'd like:

K8s's version skew policy^1 ensures that the most recent three minor releases are tested and supported.
It would be ideal if we could always ensure the latest release tested for the three most recent k8s minor versions at the data of its release. If this is valid, then with our regular release cadence, we can guarantee that there's a tested upgrade path for upgrading both TiDB operator and k8s.

Describe alternatives you've considered:

Keep an LTE version of TiDB operator. That could be challenging since some k8s upstream APIs we're using could be deprecated in the future. It's hard to keep the same TiDB operator running on all k8s versions.

Teachability, Documentation, Adoption, Migration Strategy:

Would be helpful to test against multiple k8s versions and then mention the tested k8s versions in the release notes (like this[^2] one) for each release in the future.

[^2]: TiDB operator v1.3.9 release note: https://docs.pingcap.com/tidb-in-kubernetes/stable/release-1.3.9

Start by inspecting hack/e2e.sh around line 204 to understand how the current Kubernetes version is selected and how end-to-end tests are invoked. Determine how to run those tests against the three most recent Kubernetes minor versions, then document the tested versions in each release's notes. Done means the versions are tested and clearly reported for future releases.