Fix #7522 by checking for empty byte buffers a little more

Quite a few lines have changed but that is mostly comments.
Add test for #7522
md5.c: fix a typo in the size argument of memset
throwTo is interruptible.

Signed-off-by: Edward Z. Yang <ezyang@mit.edu>
add test for #7719
Fix System.Timeout.timeout leaking Timeout exceptions (#7719).
Implement faster System.Timeout.timeout for the threaded RTS.

The basic idea is to use the Timer Manager rather than spawning an
auxilliary thread to handle timeouts; this was proposed by Bas van Dijk
two years ago (#4963), and recently by Herbert Valerio. The key idea
to make this work is to spawn an auxilliary thread for the delivery
of the Timeout exception. This idea as well as most of the code is due
to Akio Takano.
Build fix for iOS; fixes #7759

Patch from Stephen Blackheath.

The issue here is that the #defines EVFILT_READ and EVFILT_WRITE have
the values -1 and -2. The original code translates that to
filterRead = Filter -1 which is wrong Haskell and fails to compile.
The modified code produces the correct code filterRead = Filter (-1)
Fix warnings
Add some more Data.Functor functions; fixes #7817

Added infixl4 $>.
Re-exported void from Data.Functor.
Also defined the fixity for <$ for non-GHC impls.
Add Debug.Trace.{traceId,traceShowId,traceM,traceShowM}; fixes #7626
Fix #7853
Test fix for #7853
Improve documentation for mkTextEncoding
Add isLeft/isRight
Fix build on Windows
Update parallel IO manager to handle the invalid files in the same way as previous IO manager.

This patch affects the IO manager using kqueue. See issue #7773. If the kqueue backend cannot wait for events on a file, it will simply call the registered callback for the file immediately. This is the behavior of the previous IO manager. This is not ideal, but it is an initial step toward dealing with the problem properly. Ideally, we would use a non-kqueue mechanism for waiting on files (select seems most reliable) that cannot be waited on with kqueue.
Derive Typeable for RealWorld and (->), now that we can
Support for Windows DBCS and new SBCS with MultiByteToWideChar

Because MultiByteToWideChar/WideCharToMultiByte have a rather unhelpful
interface, we have to use a lot of binary searching tricks to get them
to match the iconv-like interface that GHC requires.

Even though the resulting encodings are slow, it does at least mean that we
now support all of Window's code pages. What's more, since these codecs are
basically only used for console output there probably won't be a huge volume
of text to deal with in the common case, so speed is less of a worry.

Note that we will still use GHC's faster table-based custom codec for supported
SBCSs.
Add comprehensive test for codepage encodings+recovery for them