v0.7.0

Big change for this release is the switch to per-key encrypted values.
("Keys" as in "object key/value", not as in "encryption key". English is hard.)

• Previously we generated a single big encrypted blob for each Secret, now we encrypt each value in the Secret separately, with the keys in plain text.
• This allows:
  • Existing keys can now be renamed and deleted without re-encrypting the value(s).
  • New keys/values can be added to the SealedSecret without re-encrypting (or even having access to!) the existing values.
  • Note that (as before) the encrypted values are still tied to the namespace/name of the enclosing Secret/SealedSecret, so can't be moved to another Secret.
    (The cluster-wide annotation does allow this, with the corresponding caveats, as before)
• The kubeseal tool does not yet have an option to output just a single value, but you can safely mix+match the individual values from kubeseal output with an existing SealedSecret. Improving kubeseal support for this feature is still an open action item.
• Existing/older "all-in-one" SealedSecrets are declared deprecated, but will continue to be supported by the controller for the foreseeable future. New invocations of the kubeseal tool now produce per-key encrypted output - if you need to produce the older format, just use an older kubeseal. Please raise a github issue if you have a use-case that requires supporting "all-in-one" SealedSecrets going forward.
• Note the CRD schema used for server-side validation in k8s >=1.9 has been temporarily removed, because it was unable to support the new per-key structure correctly (see kubernetes/kubernetes#59485).
• Huge thanks to @sullerandras for the code and his persistence in getting this merged!