On some (most? all?) SysV based systems with STREAMS based ptys,
sshd could acquire a controlling terminal during pty setup when
it pushed the "ptem" module, due to what is probably a bug in
the STREAMS driver that's old enough to vote.  Because it was the
privileged sshd's controlling terminal, it was not available for
the user's session, which ended up without one.  This is known to
affect at least Solaris <=10, derivatives such as OpenIndiana and
several other SysV systems.  See bz#245 for the backstory.

In the we past worked around that by not calling setsid in the
privileged sshd child, which meant it was not a session or process
group leader.  This solved controlling terminal problem because sshd
was not eligble to acquire one, but had other side effects such as
not cleaning up helper subprocesses in the SIGALRM handler since it
was not PG leader.  Recent cleanups in the signal handler uncovered
this, resulting in the LoginGraceTime timer not cleaning up privsep
unprivileged processes.

This change moves the workaround into the STREAMS pty allocation code,
by allocating a sacrificial pty to act as sshd's controlling terminal
before allocating user ptys, so those are still available for users'
sessions.

On the down side:
 - this will waste a pty per ssh connection on affected platforms.

On the up side:
 - it makes the process group behaviour consistent between platforms.

 - it puts the workaround nearest the code that actually causes the
   problem and competely out of the mainline code.

 - the workaround is only activated if you use the STREAMS code.  If,
   say, Solaris 11 has the bug but also a working openpty() it doesn't
   matter that we defined SSHD_ACQUIRES_CTTY.

 - the workaround is only activated when the fist pty is allocated,
   ie in the post-auth privsep monitor.  This means there's no risk
   of fd leaks to the unprivileged processes, and there's no effect on
   sessions that do not allocate a pty.

Based on analysis and work by djm@, ok djm@