SF bug #438295: [Windows] __init__.py cause strange behavior

Probable fix (the bug report doesn't have enough info to say for sure).
find_init_module():  Insist on a case-sensitive match for __init__ files.
Given __INIT__.PY instead, find_init_module() thought that was fine, but
the later attempt to do find_module("__INIT__.PY") didn't and its caller
silently suppressed the resulting ImportError.  Now find_init_module()
refuses to accept __INIT__.PY to begin with.

SF bug #417093: Case sensitive import: dir and .py file w/ same name
Directory containing
    Spam.py
    spam/__init__.py
Then "import Spam" caused a SystemError, because code checking for
the existence of "Spam/__init__.py" finds it on a case-insensitive
filesystem, but then bails because the directory it finds it in
doesn't match case, and then old code assumed that was still an error
even though it isn't anymore.  Changed the code to just continue
looking in this case (instead of calling it an error).  So
    import Spam
and
    import spam
both work now.

of these "search the directory" schemes (including this one) are still prone
to making mistakes.

the more recent versions of that platform, so we use the value (time_t)(-1)
as the error value.  This is the type used in the OpenVMS documentation:

http://www.openvms.compaq.com/commercial/c/5763p048.htm#inde

This closes SF tracker bug #404240.

Also clean up an exception message when detecting overflow of time_t values
beyond 4 bytes.