>> SIGWINCH handler

> Yeah, while I haven't dealt with them since 1994, signal handling is
> no fun at all.  But needed ... John et. al., is signal handling needed
> for any other future SRFIs/R7RS-large you envision?  Your GitHub repo
> https://github.com/johnwcowan/r7rs-work doesn't have any file with the
> string signal in it.  PosixLua.md, what Lua provides in it's POSIX API
> has the following:
>
> posix-signal: kill (pid, opt)
> posix-signal: killpg (pgrp[, sig=`SIGTERM`])
> posix-signal: raise (sig)
> posix-signal: signal (signum[, handler=SIG_DFL[, flags]])
>
> PosixLinks.md has this Chicken 5 egg:
>
> https://wiki.call-cc.org/man/5/Module%20(chicken%20process%20signal)
>
> If another SRFI needs signal handling, or a general POSIX signal
> handling SRFI is a good idea, facilities to supply the above desired
> SIGWINCH handler should be in it.  Even if we don't envision any of
> this today, we should still almost certainly put this in another SRFI
> because of how much of a burden it would otherwise add to an
> implementor of SRFI 205, or an "ANSI terminal fundamentals" SRFI.

Thanks for doing the above survey!

Unfortunately signal handling ties in an extremely subtle way into a
Scheme implementation's multithreading and GC systems, and probably into
continuations as well. It's a minefield even in C; in Scheme, I wouldn't
dare specify any portable signals+threads API. Let's leave that to the
experts on our lists who have maintained a multi-threaded,
cross-platform Scheme implementation for many years.

For the terminal library, all we really need is a way for someone to
notify it whenever the window size signal has been received. I'd advise
that we only export such a procedure from the ANSI terminal SRFI
(whether it's SRFI 205 or a future one).