The previous implementation returned the default datetime type in
many cases instead of raising an exception. I also changed the
hybrid C + Python implementation to be purely in C.

…datetime results

There is also a problem with 'O4' and 'O8', which are platform-specific.
I changed it to still accept both, but produce a deprecation warning.

…atetime

Doing the type promotion rules requires some datetime utility functions
which aren't written yet. In the process of setting the stage for those,
I've moved a number of functions from descriptor.c to datetime.c and
renamed them trying to more descriptively.

The 'den' metadata was always 1, except during construction, so there
is no reason for it to exist. The variable is kept in the struct
for 1.6 ABI compatibility, however.

The datetime_data function used ctypes. Moving the function to C is
no more difficult, and a bit cleaner in my opinion.

It turned out pickle roundtripping wasn't being tested, and the
changes I did broke that. This restores that functionality and
improves some error checking and formatting as suggested by Chuck.

…E_setitem

It turns out that the date-time API for converting the
npy_datetimestruct to an npy_datetime takes just the
NPY_DATETIMEUNIT, not a datetime metadata struct, but
I wanted to commit here as a checkpoint before adding
what's needed there.

Also added support for parsing events as an integer after
the time portion of the string.

The datetime64 is a parameterized type, something which can't be handled
with the simple linear list search the ufuncs currently do. This patch
adds a function pointer to the end of the ufunc object (should be
ABI compatible similar to the metadata addition in 1.4.1), which handles
type resolution. This function is set by default to a function which
executes the preexisting type resolution functionality.

Also remove some DATETIME ufuncs that didn't make sense (since
the datetime type has no zero, these functions still make sense
for TIMEDELTA).

…ts working

…rules

…datetime support

…and divide

…ime ufuncs

…ing rules

I think the right way to handle the logical operations is to
reduce them to have just a single loop with all booleans, then
use casting to get the inputs to those types. This change requires
adding custom type resolution to the reduction ufunc methods as well,
which is beyond the scope of datetime.

… more general units

…bstraction

…inting

The TimeInteger seemed like the wrong abstraction to me. Timedelta
is reasonable as an integer, and in fact if NumPy supported arbitrary
unit metadata, Timedelta could be removed and that mechanism used
instead. Datetime, however, doesn't represent an integer. Datetime
has no zero (barring big bang, God's creation, or some other choice...),
something which integers definitely have.

…ring function with several options