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.