A suggestion for a new crypto callback system

[dagle]

This pr is more of discussion and trying to fix some of the issues in gmime regarding crypto towards 4.0

This suggestion tries to fix the following problems with the current
implementation.

1. It's not introspectable. A user can't change what engine to use with crypto.
2. You can't get why the key was created. As mention in GMime 4.0 Plan #74
   this can be a problem. Maybe the flags should be bitflags.
3. Callback data. Some crypto engines can require additional data or you
   just want to save some state.

[dagle]

The idea spawned with me wanting to try different cryptoengines, I implemented a gmime-sq
which kinda is (or was, glib-rs broke it last week) swap in replacement for gpg. It's a bit naive and doesn't use the latest features of sq but it works and it can use every function of cryptocontext. Personally I would like to choose the crypto engine easily without needing to wrap a lot of C.

The reason for trigger is not only do you might need to know why a cryptocontext should be created. I want this for being able to use it with my autocrypt-storage: sequioa-autocrypt (glib/gmime bindings coming soon), rather than using a gpg keyring to store my peers and keys. This way an implementation of decryption of an autoencrypted email could be engine agnostic.

[jstedfast]

I'm open to having the crypto APIs be redesigned to allow for other drop-in crypto implementations.

[jstedfast]

I don't understand why the password callback was made global - I think it should probably remain per-context.

[dagle]

Moved it back the password function. It's now introspectable. Dunno how to rerun checks, seems to be something wrong with github atm.