Remove cluster config defaults from upgrade flow

[g-gaston]

Currently, we only trigger CP and Workers upgrade if the new cluster config (including cluster crd and some of provider specific ones) differs from the one installed in the cluster.

This could be problematic: since we set some defaults for certain fields in the config if the user hasn't provided them, we could be triggering upgrades that are not desired if those default values change from create to upgrade.

As part of #399 discussion, we agreed on implementing a behavior closer to what kubectl does, where during a resource update, unset are never updated and a 3-way merge is done with the current value of the resource. So whatever was set during cluster creation, if not overwritten explicitly by the spec file when running upgrade cluster, it will remain untouched.

This would require some refactors in the provider code, since right now setting defaults and validations are tied together. It will also probably require removing side effects from the govc executable methods. It might also require updating some of the provider logic to be able to handle the values provided by the user (like paths).

It is advised to split this work into multiple phases.