Move cross-platform clock abstraction from C to Haskell.

There are several reasons for this move. One is performance. For
compliant POSIX systems, time.h already provides all that we need,
without the need for wrapper functions. The C code used to define
a common cross-platform API, that each platform implemented differently.
But the problem with this approach is that GHC can't inline C wrapper
functions. The common API was introducing an extra layer of function
calls, but these cannot be eliminated by GHC, when it otherwise could if
the cross-platform API abstraction was done in Haskell instead.

The other reason is better portability and safety. Darwin and POSIX both
use struct timespec to encode clock readings. But because Windows does
not, the lowest common denominator was a two element array of longs.
These arrays were cast to timespec, but on some systems time_t is
32-bits, which we can't just assume to be the size of a long. On such
systsems casting would yield incorrect results. Not to mention that on
modern 32-bit systems time_t is long long, again yielding incorrect
results. Also, it's best not to rely on C's struct layout semantics to
match exactly that of a two-element array.
Make the definition of TimeSpec architecture independent.

Previously, the definition of TimeSpec was in terms of architecture
dependent types (i.e. Int does not have the same size on 32-bit and
64-bit platforms).
Mark internal helper functions for win32 as static.
Remove warnings.
Only compile the relevant cbits on each platform.

This works around a limitation of the OS X linker, which complains if
the object file exports no symbols.
Merge pull request #15 from tweag/portability-fixes

Move cross-platform clock abstraction from C to Haskell