CLN: de-duplicate boxing in DTI.get_value
Also add a dedicated test or it to hit currently un-covered case of np.datetime64 key.  That case works in master, but doesn't go through the expected code path
@jreback @jorisvandenbossche related to this PR I'm trying to de-duplicate the localization going on in _get_value_maybe_box.  Back in #17920 it was decided to localize naive-looking strings when doing lookups on a tzaware DTI, but I'm surprised that we are doing the same for datetime objects (and AFAICT also np.datetime64, but we dont test that case)

The relevant test is in tests.series.indexing.test_datetime, pulling out the pertinent part:

```
rng = date_range("1/1/1990", periods=N, freq="H", tz="US/Eastern")
ts = Series(np.random.randn(N), index=rng)

[...]
# repeat all the above with naive datetimes
result = ts[datetime(1990, 1, 1, 4)]
expected = ts[4]
assert result == expected
```

When I change the behavior of get_value to _not_ cast tznaive datetime objects, this lookup raises (which I thought was the correct behavior, but apparently not?).  Looking at the blame for this test, it has been around for a long time.

Changing this would be non-trivial because it turns out that getitem[scalar] goes through DTI.get_value but slicing and setitem etc go through different paths.

I guess there's not really a question here, just opening it up for comments. about your comment: https://github.com/pandas-dev/pandas/pull/30819#issuecomment-572281006

yeah this is the implict conversion of *strings* only to a local timezone when they are naive (the strings) and the indexing is on timezone aware indexes. note that this does *not* apply to timestamps which must be explicityly timezoned.

seems reasonable, but feel free to open an issue if more questions.

ideally we should try to limit the indexing paths, but there is a lot going on so not sure how easy this is. thanks