Check all the keys in .gpg-id are valid before adding a new key

[hackaugusto]

Summary

There are two things here:

1. This is not a bug, but an usability issue. When adding a new key with gopass recipients add --store <store> <user_id> the secrets will be re-encrypted for every key in .gpg-id. If one of this keys is expired the encryption will fail.
2. This I think it is a bug, if the encryption failed on the previous step, the new key will be added to .gpg-id even though it can't decrypt anything, running gopass fsck won't fix the issue.

Steps To Reproduce

I had this issue with a key that actually expired, I suppose these steps can reproduce the issue:

• Create a new key pair
• Add it to the password store and encrypt a secret with it
• Edit the previous key and set the expiration in the past
• Create a second key pair
• Try to add the non-expired key to the keystore

Expected behavior

A nice error message saying that one of the keys is expired, and user intervention is necessary. Either the key has to be removed from the password store, or the owner of the key has to update the expiration.

Environment

• OS: Fedora
• OS version: Linux .. 5.11.15-200.fc33.x86_64 Add template feature #1 SMP Fri Apr 16 13:41:20 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
• gopass Version: gopass 1.8.6 (d5b0d3b 2021-01-27 21:11:07) go1.15.6 linux amd64
• Installation method: compiled

Additional context

[hackaugusto]

This is similar to #1917 (comment) , here the field 7 should do the trick

[AnomalRoil]

We should at least support using an expired key to add a new recipients.

Todo:

• Add a test case for this
• Add a warning when there is such a thing, and proper documentation about what is possible to do in that case (namely: extend the private key expiration date OR remove the expired key and add a new key with a expiration date in the future)
• Add a flag to "ignore" expired keys upon re-encryption as long as there are still valid keys in the recipient list (or maybe provided we are working with a non-expired subkey related to the same master key as the expired key?)
• Make sure we cannot add or create or generate new secrets if we have an expired key: Warn the user they need to add a new non-expired key and remove the expired key.

Somewhat related to #2015 too.