Stdin handling works perfectly with the xlib backend. On backends that
rely on threading for stdin (e.g. glfw, sdl2), there are a few corner
cases:

1. only one display should ever enable stdin read: the reader thread will
   report to only that one thread it was first installed for

2. if the display is destroyed, 1..3 newlines on the input may be required
   before the application can resume normal read of stdin. This is because
   the thread can not be killed (read() interrupted) in a portable way

These does NOT affect the normal case when there's only a single display
and that display is destroyed when the application exits.


Reasons for the limitations: some systems, e.g. windows, can not select(2)
on stdin. The only way to reliably get non-blocking stdin on those systems
is using threads. Thus with backends targeting those systems, mbtk uses a
background thread constantly reading stdin using blocking read(). Once display
uninit is called, the thread is stuck in such a read() normally. Even if
stdin is disabled before the uninit: that doesn't take effect immediately
either, the command is sent but is pending until the ongoing read() returns.
There is no portable way to interrupt the blocking read(), thus the thread will
not stop reading until a newline is read.