This enables plugins to wrap file keys to identities, for example when
the plugin is built around a symmetric primitive (since we do not want
the recipients encoding to ever contain secrets).
The previous iteration of the recipient-v1 state machine assumed that
user interaction would never be required during encryption. This is
almost certainly true for asymmetric recipients, but is not the case
for symmetric recipients (e.g. the symmetric key might be stored on a
hardware token that requires a PIN).
The recipient-v1 state machine now uses a bi-directional second phase,
matching the identity-v1 state machine. It defines the same commands
for interacting with users.
