Avoid password prompting caused by --throw-keyids

When trying to decrypt a message encrypted by with this option, gpg can't tell the recepient key. Therefor it will go through all the keys in the keyring one by one prompting users for passhrases on all of them. See blake2-ppc/git-remote-gcrypt#9

This is not necessary because we know which keys are involved in the encryption of this repository. We can thus create a limited keyring and instruct gnupg to use that which will usually result in gnupg hitting the right key straight away.

Conceptually from what I can tell, with this patch the problem is solved, however on the implementation level there is quite a few problems/questions and people should not rely on this code until it is peer reviewed and improved.

Limitations:
- written by a noob in linux, shell scripting and gnupg
- not tested
- not peer reviewed
- saves secret key material in /tmp. I don't like this and would put the tmp files of gcrypt somewhere in the users /home, but gcrypt already provides a facility for temp files and the cleanup thereof, so it is not appropriate to be inconsistent here, but the safety of this system should be investigated and final choices justified to the end user. I would have preferred to keep the key material in process memory rather than writing to disk, but my limited shell scripting prevented me from succeeding in that.
- the function is still dense, with little documentation and code formatting, and thus cryptic, but that is consistent also with the rest of the script.
- I opted to make Conf_part (the participant keys) globally available for this, whereas probably it is the signing key we are interested in. I am not sure which scenarios might exist where one might need to decrypt with another key than the signing key. If none can reasonably be found we might as well undo making Conf_part public.
- it is assumed that $Conf_signkey and $Conf_part are in a compatible format to be fed to gpg separated with a space
- it is assumed that the pid ($$) provides enough randomness for the keyring temp files. Normally there is no other place where we need them, and we should garantee their cleanup.