Improve major version upgrades

[pebrc]

#231 introduces robust support for running different versions of the Elastic stack with the k8s operator but we don't have any support yet for the subtleties of migrating from one version to another.

Ideas

• report unsupported version upgrades via status + events
• implement upgrade checks when upgrading from version n to m
  Using either the Kibana upgrade assistent APIs and or deprecation API to identify issues where possible
• Prevent skipping a version and other version related invariants (e.g. 6.7-> 7.0) via a validating admission controller

[pebrc]

A rolling upgrade is only possible from 6.7. because 7.0 as of beta1 (?) no longer supports minimum master nodes and only 6.7 publishes m_m_n in cluster state (see elastic/elasticsearch#37701). That means in practical terms that a 7.0 node cannot join a 6.x cluster unless that cluster is >= 6.7

[pebrc]

Decided to pursue only #464 and record/express the inability to upgrade via a new status (something like precondition failed) and events (could not upgrade because ...)

[pebrc]

See #312 for details of PVC reuse which also applies to major version changes.