Pass environment variables from rbw to rbw-agent

[wfdewith]

I use rbw on a workstation with X.org, but also regularly connect through SSH from my laptop. This setup causes issues with the rbw-agent, since it is started by the first rbw command, and inherits the environment from there. rbw-agent is responsible for starting pinentry. If I run rbw first in my X session, rbw-agent will always start pinentry in the X session, even if I run rbw from an SSH session. Vice-versa, when first starting rbw from an SSH session, rbw-agent, and therefore pinentry never inherits the X session and it will always prompt through its curses UI.

I never had this issue when I was still using pass with GPG, even though GPG's architecture is similar to rbw in that the gpg-agent process is responsible for starting the pinentry process. I investigated the GPG source code to see what gpg-agent does differently compared to rbw to make pinentry always use the environment where gpg was executed.

As it turns out, GPG maintains a list of environment variables that are read from the gpg process and passed through gpg-agent to the pinentry process. Since rbw already does something similar with the TTY, I extended that functionality in this PR to add environment variables as well. In addition, GPG allows overriding the TTY through the GPG_TTY environment variable, so I added an RBW_TTY variable as well.

It's fairly hard to grok the GPG source code, since it mostly interacts with pinentry through libassuan (which is the protocol used by pinentry), so not everything is communicated through environment variables and there are multiple entry points (gpg is not the only process that uses gpg-agent). However, I am reasonably confident that I've extracted the relevant parts, and the current state of this PR should be functional. That said, I haven't tested all the different environment variables. You can try the main idea by switching between X and non-X TTYs and interacting with rbw. I haven't tested Wayland, so if someone has a Wayland desktop, I'd like to know if that works as expected.

Finally, I've updated rbw-pinentry-keyring such that the pinentry invocations inherit the arguments passed into the script. This should resolve the issue described in #196.

[doy]

applied, thanks!