Consider a situation where the user passes "--status-fd 3" but file descriptor 3
is not open.

During the course of executing the rest of the commands, it's possible that gpg
itself will open some files, and file descriptor 3 will get allocated.

In this situation, the status information will be appended directly to whatever
file happens to have landed on fd 3 (the trustdb? the keyring?).

This is a potential data destruction issue for all writable file descriptor options:

   --status-fd
   --attribute-fd
   --logger-fd

It's also a potential issue for readable file descriptor options, but the risk
is merely weird behavior, and not data corruption:

   --override-session-key-fd
   --passphrase-fd
   --command-fd

Arguably, this is user error (to assign a file descriptor that hasn't already
explicitly been set up), so it's not a very friendly error mode, and gnupg
should include as few footguns as possible.