A frequent operation is to take an existing sealed secrets and update a single entry in it.

We even have a fancy command now that helps this tedious operation: `--merge-into` (documented in the README).

The rationale for implementing that command was not only to help lazy users to merge strings into the right place
into a YAML file but also to address one of the most common and confusing user errors:

```bash
$ echo -n foo | kubectl create secret generic goodname --dry-run  --from-file=bar=/dev/stdin -o json \
  | kubeseal >sealed.yml
$ echo -n bar | kubectl create secret generic baadname --dry-run  --from-file=bar=/dev/stdin -o json \
  | kubeseal --merge-into sealed.yml
```

It's even more subtle when the namespace is concerned, since it's often taken from the current kubeconfig context.

This PR turns `--merge-into` into what it was intended: a helper that helps, leaning more on the "do what I mean"
rather than blindly "do what I told you":

It treats the state of the existing sealed secret the user is merging new values into as the home for the sensible
parameters of the sealing process.

A subsequent PR will do something similar for the "scope", since that also affects how the entries are encrypted and has subtle consequences when you get it wrong (and it's harder to deal with in one-liners, since you cannot set an annotation during `kubectl create secret...`).

---

Enhances the tests for the mergeInto command so that they also decrypt the values.
This resulted in a noisy refactoring due to the fact that until now the kubeseal code only encrypted values
using a dummy public key for which we had no private key.