API changes for client cert auth

[Lucas Fisher]

I'm going to need to make some purple API changes in order to enable client 
certificate authentication. We now have private keys that we need to manage and 
protect. I see three general strategies on how to do this:

1. Have the x509 scheme include the private key in PurpleCertificate.

The key would be another field in the x509 scheme's private data. Certificates 
that don't have an assoicated key would just set this field to null.
This allows resuse of much of the existing certificate code, but some of the 
existing API is inadequate. First the private keys must be protected on disk 
which means encrypted with a password. The existing PurpleCertificateScheme and 
PurpleCertificatePool offer no means of specifying a password when 
importing/exporting  or  getting/putting a certificate with a key. New 
functions would need to be added to both APIs to allow passing of a password. 
This can probably be done by just using up some of the reserved slots in 
PurpleCertificateScheme and PurpleCertificatePool.

2. Create a completely separate API for private keys.

This would replicate most of the Certificate API and tailor it for private 
keys. Basically creating PurplePrivateKeyScheme and PurplePrivateKeyPool that 
allow passing a password to the relevant key import/export and pool get/put 
functions. The libpurple user would then be responsible for ensuring they can 
correlate a certificate with a private key which should be easy if you just use 
the same id. I think it would also avoid making any API changes that would 
break binary compatibility, but I'm not sure of this.

I would also have to stick a PKCS12 import/export function in here somewhere 
since that is how most people would have their certs and keys available 
outside of libpurple.

3. Create a completely separate API for client credentials.

This would be another scheme and pool that would replicate the Certificate API 
but handle both certificates and private keys. So it would be simliar to 
strategy 1 but a separate API. Basically, the existing Certificate API but with 
means to pass passwords.  So it would be simliar to strategy 1 but a separate 
API. This would probably be backed by PKCS12 files in most implmentations. It 
could also eliminate the need to have a separate PKCS12 API that would be 
needed in 1 & 2.

Feedback on any issues that I missed, alternative solutions, or preferences 
from the project are appreciated.

Lucas