BUG: isin incorrectly casting ints to datetimes
- [x] closes #36621
- [x] tests added / passed
- [x] passes `black pandas`
- [x] passes `git diff upstream/master -u -- "*.py" | flake8 --diff`
- [x] whatsnew entry

De-duplication in follow-up.
> this going to need perf tests as this is very sensitive

will run the appropriate asvs actually, i think this can be simplified to just use _from_sequence following #37179 gentle ping.  id like to see if we can share some code between this and `equals` Found we don't have any asvs that hit this, so just added a few.  No change for cases with matching dtype, nice pickup for others:

```
       before           after         ratio
     [f823a859]       [9758b021]
     <ref-dtlike-indexers>       <bug-dti-isin>
-        691±30μs          143±3μs     0.21  series_methods.IsInDatetime64.time_isin_empty
-     1.23±0.08ms          141±8μs     0.11  series_methods.IsInDatetime64.time_isin_mismatched_dtype

SOME BENCHMARKS HAVE CHANGED SIGNIFICANTLY.
PERFORMANCE INCREASED.

``` I guess as a short term measure this is ok as you fixed some bugs. the problem here is that you are bouncing between algos and the indexes, where everything should be in algos. this feels like a step backwards, if its tactical, then ok. > the problem here is that you are bouncing between algos and the indexes, where everything should be in algos

its not unusual for core.algorithms functions to call EA methods.  There's no way the casting logic belongs in core.algorithms. > > the problem here is that you are bouncing between algos and the indexes, where everything should be in algos
> 
> its not unusual for core.algorithms functions to call EA methods. There's no way the casting logic belongs in core.algorithms.

that's not what's happening here, these are calling Index methods. This seems quite unusual and a very odd depenency.
Why do you not simply move the logic in DTI.isin back to algorithms? what's the point of adding this depenedecy.? > that's not what's happening here, these are calling Index methods

Good point, my mistake.  At some point this should be consolidated in the EA.  IIRC theres an issue about adding `isin` to the interface.

> Why do you not simply move the logic in DTI.isin back to algorithms? 

because the relevant logic is _casting_ logic that belongs in the DTA.  My current thought is that once we get the _from_sequence-strictness PR in we'll be able to de-duplicate some logic between isin+equals using that.

 The new hashtables have me looking at algorithms._ensure_data, and I'm pretty confident that this will allow us to simplify it quite a bit