Feature request: support controlled mysqld version upgrade with rollback

[maxenglander]

Currently the way to upgrade from mysql 57 to 80 in the operator is to change mysqld image version. This causes operator to do a rolling upgrade of tablets. There's a lot that could go wrong here, and it would be nice if there were an option to do a controlled migration from 57 to 80.

One way this could work in theory is to create a new keyspace configured with mysql 80, and do a MoveTables from the 57 keyspace to the 80. This would allow carefully testing and validating that the upgrade succeeded before doing SwitchTraffic, and in theory would allow switching back to 57 if issues were discovered in 80 after SwitchTraffic (modulo reverse replication issues).

Assuming this idea is sound, what would be needed is to patch the operator to allow specifying mysqld image per keyspace. Currently this is not allowed, and the docs say:

vitess-operator/docs/api.md

Lines 5280 to 5283 in 5bf4279

	<p>Images are not customizable by users at the keyspace level because version
	skew across the cluster is discouraged except during rolling updates,
	in which case this field is automatically managed by the VitessCluster
	controller that owns this VitessKeyspace.</p>

[deepthi]

Currently the way to upgrade from mysql 57 to 80 in the operator is to change mysqld image version.

Just noting that this doesn't really work right now because the default collation in 8.0 does not exist in 5.7 and we are not setting an explicit collation in the mysql config file.

See #369