Stop generating labels with NUL bytes at the end

[dmjones]

If users don't pass a label or ID to the key generation functions, one is generated for them. This value will typically have ~20 NUL bytes at the end, which causes problems if users convert to/from strings using string(<some bytes>) and []byte(<the string>). This kind of simple string conversions will discard NUL bytes, resulting in a different label or ID.

We should adjust this behaviour and return non-NUL data. I would suggest generating random bytes, converting to hexadecimal characters, then returning the bytes of that hexadecimal string.

[dmjones]

Of course, I argue strongly in #15 for us to drop key generation and I still intend to do that. But fixing this prior to deprecating those functions seems friendly.

[mrangana]

From the pkcs11 spec, the label is of type string.

Section: "4.4 Storage Objects" CKA_LABEL RFC2279 | string | Description of the object (default empty)."