The dtype name for datetime64 and timedelta64 shouldn't strip off the "64"

[jpivarski]

I've been making unit tests for the C++ → Python transition and found out how the datetime types are being made consistent with Datashape:

https://github.com/scikit-hep/awkward-1.0/blob/94de4e5112ad3a2d5fc9c2ec0fc29e242543a0d6/src/libawkward/util.cpp#L73-L78

and

https://github.com/scikit-hep/awkward-1.0/blob/94de4e5112ad3a2d5fc9c2ec0fc29e242543a0d6/src/libawkward/util.cpp#L119-L122

But this means that in all other contexts, the name has the "64" stripped as well. This is inconsistent with our other uses of dtypes, and that's worse than being inconsistent with Datashape. Moreover, Datashape is not consistent with itself: all the other types, "int8", "int32", "int64", "float64", etc., have the bit width in their names.

So I'd like to go back on this, to let datetime64 and timedelta64 have the "64" in their names, foregoing strict adherence with Datashape (which we're not completely keeping anyway: it doesn't look like they'll ever add unions and such, which we need blaze/datashape#237).

@ianna, please revert the names of datetime64 and timedelta64 to have the "64" at the end, before anything starts to depend on it. Thanks!

[ianna]

@jpivarski - I think, this is one can be closed