Key material should have a consistent and safe format

The private keys produced by `glome genkey` (and the corresponding public keys from `glome pubkey`) are x25519 keys, i.e. 32 raw octets.

### Key Exchange

Dealing with GLOME keys is inconvenient: transferring a public key to another system requires either a direct file transfer (e.g. `scp`) or an intermediate encoding into the printable range (e.g. `base64`). SSH keys, for comparison, are PEM encoded and can be easily copied or included in an email. Furthermore, given only the key file it is impossible to determine its nature, which could lead to accidental confusion of private and public keys. In the best case, you just cannot determine whether the 32B file in your home directory created two years ago is a GLOME key or something else.

### Encoding Logic

All keys in the spec are hex-encoded, as are the keys in tests and for `glome-login`. The lack of encoding in the GLOME library causes a proliferation of encoding logic elsewhere, as can be seen by the definition of a `decode_hex` in `glome_test.c`, `cli/commands.c` and `login/ui.c`. Since parsing and deserialization logic is a common source of security vulnerabilities, it would be better to have one central piece of logic for dealing with encoding that is well tested.

### Protocol Variants

The keys do not specify which protocol variant they are to be used with. If the two parties disagree on the variant to be used we would at least expect mismatching tags, while a deliberately introduced confusion by a person-in-the-middle could ostensibly lead to more severe outcomes.