Cancel UI should have well-defined semantics.

Let us consider a scenario of decryption (with multiple methods).

Current situation:

• gpg supports cancelling one method. Canceled -> it tries another method.
• gpgme considers that single GPG_ERR_CANCELED means cancelling the whole process of decryption.
• pinentry-tty and pinentry-curses support GPG_ERR_FULLY_CANCELED by Ctrl-C. But other pinentry implementations have no support (only GPG_ERR_CANCELED).

We could have clear definition like:

• GPG_ERR_CANCELED means cancelling one method
• GPG_ERR_FULLY_CANCELED means cancelling all (cancelling the whole process of decryption)
• meaning of empty input depends on the context (for symmetric encryption, meaning "skip", for example)

If this definition is OK, then we will do:

• Enhance other pinentry implementations to raise GPG_ERR_FULLY_CANCELED (for example, offering another button or new semantics of closing the dialog forcibly).
• Modify gpgme state-machine
  • not raise an error by a single GPG_ERR_CANCELED, just record it.
  • raise an error by GPG_ERR_FULLY_CANCELED
  • at the EOF, recorded GPG_ERR_CANCELED raise an error
  • observing new pinentry invocation, clears the cancel record
• Modify gpg
  • When pinentry returns GPG_ERR_FULLY_CANCELED, cancel all methods