BUG: DataFrame from dict with non-nano Timedelta
- [ ] closes #xxxx
- [x] [Tests added and passed](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#writing-tests) if fixing a bug or adding a new feature
- [x] All [code checks passed](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#pre-commit).
- [x] Added [type annotations](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#type-hints) to new arguments/methods/functions.
- [ ] Added an entry in the latest `doc/source/whatsnew/vX.X.X.rst` file if fixing a bug or adding a new feature.

xref #44504

This is motivated by a branch (upcoming PR) that makes the Timedelta constructor preserve resolution when passed a np.timedelta64 object.  Without this change, test_constructor_dict_timedelta64_index fails because of a dict lookup in lib.fast_multiget.

For non-nano Timedeltas this does significantly hurt performance:

```
In [1]: import pandas as pd
In [2]: td = pd.Timedelta(days=1, minutes=3)
In [3]: td2 = td._as_unit("ms")

In [4]: %timeit hash(td)
145 ns ± 15.5 ns per loop (mean ± std. dev. of 7 runs, 10000000 loops each)  # <- main
131 ns ± 3.43 ns per loop (mean ± std. dev. of 7 runs, 10000000 loops each)  # <- PR

In [5]: %timeit hash(td2)
138 ns ± 16.8 ns per loop (mean ± std. dev. of 7 runs, 10000000 loops each)  # <- main
1.8 µs ± 42.3 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each)  # <- PR
```

I expect there's room for optimization.  Something like:


```
if self._is_in_pytimedelta_bounds() and not self._has_ns():
    return timedelta.__hash__(self)
else:
    return self._hash_version_in this_pr()
```
This pull request is stale because it has been open for thirty days with no activity. Please [update](https://pandas.pydata.org/pandas-docs/stable/development/contributing.html#updating-your-pull-request) and respond to this comment if you're still interested in working on this. Thanks @jbrockmendel 