BUG/ENH: cleanup for Timedelta arithmetic
Fixes #8813 
Fixes #5963
Fixes #5436

If the other argument has a dtype attribute, I assume that it is ndarray-like
and convert the `Timedelta` into a `np.timedelta64` object. Alternatively, we
could just return `NotImplemented` and let the other type handle it, but this
has the bonus of making `Timedelta` compatible with ndarrays.

I also added a `Timedelta.to_timedelta64()` method to the public API. I
couldn't find a listing for `Timedelta` in the API docs -- we should probably
add that, right?

Next up would be a similar treatment for `Timestamp`.

CC @immerrr

Regarding `to_timedelta64`, I suppose it already exists as the `asm8` attribute. But maybe adding such a method could be useful for visibility? 
 `to_timedetta64()` is fine (and adding `to_datetime64()` ok too). These are corresponding to `to_timedelta()/to_datetime()` and return the underlying object (and not the value, which is what `asm8` does).
 #5963 & #5436 might already be fixed / related. So might be able to just add in a couple of tests (or if they are enough there, lmk; e.g. pretty sure offsets already work).
 @jreback Yep, those issues are indeed fixed. I added a bunch of tests and everything is passing now.
 @shoyer looks good, some minor doc-like fixes.

FYI, you need to list each issue sepately with (closes/fixes) in order to have it close them when merged.

pls squash and ping when ready
 #5963 was actually already fixed prior to this PR, but I'll note it anyways :).
 @jreback looks like we're ready.
 thanks
