More coherent slot support

[optnfast]

Currently:

• Via Configure you can specify a token by label or serial, but you can't get the slot number where that token resides back out.
• You can generate a key on the configured token, but you can't specify the new key's label or ID.
• You can generate a key on a numbered slot, but you have to find the slot yourself.
• You can generate a key on a specific session, but you have to open and close the session yourself.

None of this is insurmountable but it does leave a lot of work for the callers of the key generation APIs.

(The situation is better for finding keys, but see #16).

I propose the following changes:

1. GenerateDSAKeyPair, GenerateECDSAKeyPair, GenerateRSAKeyPair and GenerateSecretKey all get id and label arguments, consistent with the other Generate... functions. This is an incompatible change, but since the functions are almost useless I don't foresee much downstream fallout.
2. withSession will become WithSession, allowing applications to play nicely with the library's own session management.
3. WithSession will take a PIN argument rather than using the configured PIN. The present callers of withSession will use the configured PIN.
4. The logic in Configure to find a slot given a token label/id will be exposed as a public function.

[nickrmc83]

I'm down with exposing a key id. In general I wonder whether we need more of an interface around keys if we want to set labels as they're mutable. In addition I wonder if we should have a "factory" interface around tokens for generating, deleting and listing keys and managing said token.

[dmjones]

The scope of this library should remain small. Do one thing and do it well.

The goal was to provide PKCS#11 implementations for Go crypto interfaces. This would allow HSMs to be used in the "pluggable" parts of the Go crypto ecosystem (e.g. crypto.Signer).

The Go crypto packages provide no interfaces key generators and thus no way to approach this in a pluggable fashion. I see no benefit in providing a partial solution for key generation, when miekg/pkcs11 offers full access to the HSM.

The potential exception to this is session keys, which cannot currently be generated in separate calls to miekg/pkcs11 and used with our library. However, if people bump into that requirement, we should analyse it separately and consider all possible solutions.

IMO, key generation was scope creep and we will probably remove it in the future (with a suitable deprecation period). Consequently, I don't see a benefit in enhancing the existing support.

[dmjones]

I'm closing this. Comments on the new design are welcome at #36.