Consistent ordering for map keys

[cowwoc]

Is your feature request related to a problem? Please describe.
Map keys have an undefined ordering; however, from a UI perspective it is annoying to see the order of keys change when Secret values are decoded (using x key).

Describe the solution you'd like
Pick an ordering and stick to it so long as we are viewing the same resource. Decoding secret keys should not change their ordering.

[ChrisMcD1]

I tried experimenting with this, and got pretty far in https://github.com/ChrisMcD1/k9s/tree/fixing-secrets-ordering before realizing that fundamentally there would need to be a canonical order implemented on top of the describe. I had hoped that we could re-use the random mapping already being shown to the user, but when when hitting x, it triggers a full call back to k8s to get the secret before re-rendering. The prior order that the user saw is not available when re-rendering the decoded version.

So to implement this, I think we would need to make the normal describe operation more complicated, whereas right now it is just a basic call to k8s describe.

k9s/internal/dao/secret.go

Lines 23 to 32 in bccea4b

	func (s *Secret) Describe(path string) (string, error) {
	encodedDescription, err := s.Generic.Describe(path)
	if err != nil {
	return "", err
	}
	if !s.decode {
	return encodedDescription, nil
	}

Secret is already a bit special though in that it has a custom Describe method to handle the existing decoded view, so maybe there is some room to make it double special by always giving it sorted rows?