API/DEPR: re-instate timedelta[non-unit] conversions as a no-op
when I originally added first class timedelta support I allowed ``.astype('m8[unit]')`` to return a float, except if unit==ns. IOW it was de-facto the same a dividing by ``Timedelta(1, unit=unit)``

```
In [1]: s = Series(pd.to_timedelta(['1 day', '1 minutes', '1 second']))

In [2]: s
Out[2]: 
0   1 days 00:00:00
1   0 days 00:01:00
2   0 days 00:00:01
dtype: timedelta64[ns]

In [3]: s.astype('timedelta64[s]')
Out[3]: 
0    86400.0
1       60.0
2        1.0
dtype: float64

In [4]: s / pd.Timedelta('1 s')
Out[4]: 
0    86400.0
1       60.0
2        1.0
dtype: float64

In [5]: s.astype('timedelta64[ns]')
Out[5]: 
0   1 days 00:00:00
1   0 days 00:01:00
2   0 days 00:00:01
dtype: timedelta64[ns]

```

note that for [5], however we just return a timedelta64[ns] (which happens to be the underlying data representation).

#19224 fixes construction of non-ns (and preserves the astype freq conversions. I think that this is confusing to the user and we should revert this and have a ``m8[unit]`` just work the same as it does for ``M8[unit]`` namely that you get back a timedelta dtype (and not a float), **that is the same**

So [3] would be the same as [5]

We do this for datetime types now
```
In [13]: Series(pd.date_range('20170101', periods=3)).astype('M8[s]')
Out[13]: 
0   2017-01-01
1   2017-01-02
2   2017-01-03
dtype: datetime64[ns]
```

sure this is slightly convenient but a bit confusing.

I would propose that we provide a deprecation warning and change it in the next version.