BUG: Raise when casting NaT to int
- [x] tests added / passed
- [x] passes `black pandas`
- [x] whatsnew entry

Fixes a bug in `astype_nansafe` where `NaT` was ignored when casting a datetime or timedelta to `int`.  I put the test in `pandas/tests/dtypes/test_common.py` since I couldn't find another place where `astype_nansafe` was tested.  Also adds various other tests for `astype_nansafe`.

Related: https://github.com/pandas-dev/pandas/pull/28438
is there a user visible level that hits this? This hits both Series.astype, Index.astype, and DataFrame.astype

```python

In [6]: a = [pd.Timestamp('2000'), pd.NaT]

In [7]: pd.Series(a).astype(int)
Out[7]:
0     946684800000000000
1   -9223372036854775808
dtype: int64

In [8]: pd.Index(a).astype(int)
Out[8]: Int64Index([946684800000000000, -9223372036854775808], dtype='int64')

In [10]: pd.DataFrame({"a": a}).astype(int)
Out[10]:
                     a
0   946684800000000000
1 -9223372036854775808
```

In addition to the `astype_nansafe` unit tests, we'd ideally also test these user facing ones.

And we should double check: we want this behavior right? Some people *may* be relying on this behavior (treating `pd.NaT` as `iNaT`). This feels like a bigger change than https://github.com/pandas-dev/pandas/pull/28438/files. I might prefer a warning first that this will change (though how would people work around it?). Did we decide on whether we're going to deprecate this behavior before changing it? IMO, ew should > Did we decide on whether we're going to deprecate this behavior before changing it? IMO, ew should

I'd defer to you guys on that one.  If we deprecate, the change would be to use a deprecation warning instead of an error and xfail the tests? > Did we decide on whether we're going to deprecate this behavior before changing it? IMO, ew should

@TomAugspurger you feel strongly about this? I don't think its a big deal, but we could deprecate. Not *too* strongly, just a slight preference. I could go either way.

On Thu, Sep 26, 2019 at 9:28 AM Jeff Reback <notifications@github.com>
wrote:

> Did we decide on whether we're going to deprecate this behavior before
> changing it? IMO, ew should
>
> @TomAugspurger <https://github.com/TomAugspurger> you feel strongly about
> this? I don't think its a big deal, but we could deprecate.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <https://github.com/pandas-dev/pandas/pull/28492?email_source=notifications&email_token=AAKAOIT4X7EAX2U27B7IYLDQLTBH7A5CNFSM4IXYP7Z2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7VYO7I#issuecomment-535529341>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AAKAOIXMNRQ27VC6JNSNIRLQLTBH7ANCNFSM4IXYP7ZQ>
> .
>
 Given how unusual the current behavior is, I'd be surprised if anyone was relying on it.  I'd say it's more likely to be a source of unexpected bugs. Is there a legitimate use case for using `astype` that we know of? The rules here wouldn't even match numpy right?

Does seem kind of buggy so I think OK without deprecation too @dsaxton can you merge master to be sure? I think we can move forward with this as is, unless @TomAugspurger you feel otherwise can you merge master @jreback all green - OK to merge? can you merge master and we'll look again lgtm. @jbrockmendel if you'd have a glance (and merge if ok) thanks @dsaxton