tty: Declare dummy curses_cmd_handler.

* tty/pinentry-tty.c: Declare a dummy handler for the
curses_cmd_handler for fallback.

This is needed for building pinentry-tty, which links to a copy of the
pinentry object which doesn't have curses (it makes no sense to
fallback from tty to curses). But the new cmd_info in
pinentry/pinentry.c needs some sort of value to test against when
reporting the flavor.

You can replicate this linker error from git with:

./autogen.sh
./configure --enable-maintainer-mode \
  --enable-{fallback-curses,pinentry-tty} \
  --disable-{inside-emacs,libsecret} && make

Which produces:

gcc  -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -Wformat -Wno-format-y2k -Wformat-security -W -Wno-sign-compare -Wno-missing-field-initializers -Wdeclaration-after-statement -Wno-pointer-sign -Wpointer-arith   -o pinentry-tty pinentry-tty.o ../pinentry/libpinentry.a ../secmem/libsecmem.a -lassuan -L/usr/lib/x86_64-linux-gnu -lgpg-error -L/usr/lib/x86_64-linux-gnu -lgpg-error  -lcap
../pinentry/libpinentry.a(pinentry.o): In function `cmd_getinfo':
«BUILDDIR»/pinentry/pinentry.c:1457: undefined reference to `curses_cmd_handler'
collect2: error: ld returned 1 exit status
Makefile:410: recipe for target 'pinentry-tty' failed
make[2]: *** [pinentry-tty] Error 1
make[2]: Leaving directory '«BUILDDIR»/tty'

One could argue that developers who --enable-tty then must also
--disable-fallback-curses, but that would just mean that it's
impossible to't build one of the graphical pinentries at the same time
(with curses fallback) as you are actually building pinentry-tty.
Arguably, though, the ./configure script should figure out the right
thing to do in this case and the build each variant sensibly.

This patch is a hack to ensure that pinentry-tty continues to link
properly even when other pinentries are being built concurrently with
a curses fallback.

• Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>