[Feature] Hold vtgate spec changes until vttablet spec changes are fully deployed (or vice-versa)

updateStrategy: Immediate of vitess-operator releases changes to all Vitess components simultaneously, including vtgate & vttablet. We have seen elevated impact when vtgate & vttablets are being rolled out concurrently. As PRS relies on vtgate query buffering to make the failover transparent to the client.

Vitess-Operator already handles staggered way of deploying changes by ensuring only one vttablet in a shard is updated at any point of time. So it makes sense to extend this pattern to ensure that vtgate changes are not released when vttablet changes are in progress or vice-versa.

Ask: Either modify the "updateStrategy: Immediate" to hold vtgate until all vttablets are upgraded OR add a updateStrategy strategy that does this.
This way, we can deploy changes to the VitessCluster CRD Spec and continue to use the "Immediate" way of automatically deploying the changes in a safe manner.

https://github.com/planetscale/vitess-operator/issues/473 proposes to address this in a different approach, bringing in user-input to the process. The feature request I am proposing is to improve the automated deployment process to be more safer.

No files or tests are named. Start by tracing how updateStrategy: Immediate handles VitessCluster CRD changes and coordinates vtgate and vttablet rollouts; compare that behavior with the existing one-vttablet-at-a-time deployment. Done means vtgate and vttablet changes are not rolled out concurrently, with coverage for the selected strategy.