Use name as fallback merge-key

This change uses the attribute name if x-kubernetes-patch-merge-key is not the full x-kubernetes-list-map-keys to avoid data corruption.

In particular:

Use x-kubernetes-patch-merge-key only if it agrees with x-kubernetes-list-map-keys.

If x-kubernetes-patch-merge-key doesn't agree with x-kubernetes-list-map-keys, then use the property name if it is present. This then matches the expectation where

template.spec.containers.test = {
  ports.dns-tcp = {
    containerPort = 54;
    protocol = "TCP";
  };
  ports.dns-udp = {
    containerPort = 54;
    protocol = "UDP";
  };
};

gets transformed into

ports:
- containerPort: 54
  name: dns-tcp
  protocol: TCP
- containerPort: 54
  name: dns-udp
  protocol: UDP

If name is not specified, this needs the workaround using __kubenix_list_merge_key_ in mergeValuesByKey and submoduleWithMergeOf to not change the original definition when specifying submodules as a list. Then

template.spec.containers.test = {
  ports = [
    { containerPort = 53;
      protocol = "TCP";
    }
    { containerPort = 53;
      protocol = "UDP";
    }
  ];
};

gets transformed into

ports:
- containerPort: 53
  protocol: TCP
- containerPort: 53
  protocol: UDP

As of kubernetes 1.26, this affects ContainerPort, TopologySpreadConstraint, and ServicePort where x-kubernetes-patch-merge-key is not equal to x-kubernetes-list-map-keys.
What doesn't work anymore is to do
```
template.spec.containers.test = {
 ports."55" = {};
};
```
which previously would have been transformed into
```
ports:
- containerPort: 55
```
This is because in order to not discard ports with the same port number, but differing protocol, both would need to be encoded into the attribute name. And because I couldn't find a nice way to make this work, I chose to go with name as the merge key instead.

closes hall/kubenix#13

hall / kubenix

Use name as fallback merge-key #21