Disable the X server input thread by default on Hammerhead/illumos.

XLibre's threaded input (INPUTTHREAD, default on for non-Windows) runs a
separate input thread whose ospoll uses the Solaris event-ports backend
(port_getn / portfs). On illumos the input->main wakeup self-pipe fd is
re-armed reporting POLLIN "ready" every cycle with nothing to deliver, so
the input thread and the main thread ping-pong on that pipe as fast as the
CPU allows: measured ~340k portfs+write/s on [InputThread] and ~225k
portfs+read/s on [MainThread] = TWO fully pegged cores at idle (conky read
CPU 247%, load avg 2.0), and a sluggish pointer because the saturated main
thread services real motion late. The kbd/consms device fds themselves were
fine (no repeated reads, errno 0) - it is purely the threaded-input wakeup
pipe. Xvfb never hit this (no real input devices, no input thread).

XLibre REMOVED the historic `-noThreadedInput` command-line flag (only
`-dumbSched` still sets InputThreadEnable = FALSE, but that also disables the
smart scheduler). Rather than depend on a launch flag that a boot service or
.xinitrc could forget - reintroducing a 200%-CPU mystery - flip the compiled
default so a plain `Xorg` invocation is correct. Input is then serviced in
the main dispatch loop (the pre-2016 default; fully functional). The smart
scheduler is left untouched. All InputThread machinery stays compiled in, so
`-dumbSched`/future flags could still toggle it.

This is an illumos/Solaris-specific XLibre defect (event-ports ospoll re-arm
vs. the threaded-input self-pipe); XLibre CI has no illumos target. Worth
filing upstream. Complements 0002-ospoll-port-listener-rearm.

--- a/os/inputthread.c
+++ b/os/inputthread.c
@@ -44,7 +44,7 @@

 #if INPUTTHREAD

-Bool InputThreadEnable = TRUE;
+Bool InputThreadEnable = FALSE;

 /**
  * An input device as seen by the threaded input facility