Fix adding authorized keys in Kubernetes and Slurm

[un-def]

The Kubernetes jump pod added the user's key with grep -qvF KEY file, which asks whether some line does not contain the key, not whether no line contains it. The jump pod's authorized_keys holds the project key, so the condition held whether or not the user's key was already there, and every run appended another copy of it. Users keep the same key across runs, so the file of a jump pod, shared by the whole namespace, grew by one duplicate per run. Had the file been empty, the condition would have been false and the key never added at all.

Slurm got the condition right, but matched the whole entry, comment included, so the same key submitted with a different comment was added a second time.

All three implementations -- SSH fleets, Kubernetes, Slurm -- are replaced with get_add_authorized_keys_script(), extracted from the SSH fleet one, the only one of the three that was correct. It returns the script instead of running it, as the call sites execute it in three different ways: paramiko, ssh over the jump pod, and the Slurm client.

• Keys reach the script as heredoc data instead of being interpolated into its commands, so the shell never parses anything that came from a key.
• Entries are rebuilt from parse_public_key(), a new helper parsing a public key in OpenSSH disk format, so that nothing unvalidated is written to the file. A key that fails to parse is skipped with a warning: one bad key does not keep the rest out of the file.
• Entries are deduplicated on the key blob alone, since neither the comment nor the command="/bin/false" options Kubernetes and Slurm prepend are a part of the identity of a key.
• Kubernetes and Slurm entries now carry the # added by dstack marker the SSH fleet entries have carried since Don't add duplicate keys while provision SSH instance #4179.