PERF: define is_all_dates to shortcut inadvertent copy when slicing an IntervalIndex
We get a few orders of magnitude speedup in `IntervalIndex` slicing by simply overriding the base class definition of `is_all_dates`, like all other `Index` derivatives also do. The root cause of the performance degradation is as follows:

- When slicing a `Series`, a new `Series` is created for the result.
- The last step in `Series.__init__()` is `Series._set_axis()`, which in turn calls `.is_all_dates` on the new `Index`
- The base definition of `Index.is_all_dates` is:
```    
@cache_readonly
def is_all_dates(self):
    if self._data is None:
        return False
    return is_datetime_array(ensure_object(self.values))
```
which seems harmless at first glance. However, this eventually invokes `IntervalArray.__array__`, which is a pure Python for-loop creating `Interval` objects and leading to the performance regression here.

As the value of `IntervalIndex.is_all_dates` appears to always be `False`, even in the case of datetime-like left/right values, we simply override to return that value and shortcut the inadvertent copy described above.

### Benchmarks
```
       before           after         ratio
     [ce62a5c1]       [a8f5e90b]
     <interval_index_fix~1>       <interval_index_fix>
        3.42±0.6s          446±0μs    ~0.00  indexing.IntervalIndexing.time_getitem_list
         101±50μs          103±0μs     1.02  indexing.IntervalIndexing.time_getitem_scalar
-      3.80±0.08s          355±0μs     0.00  indexing.IntervalIndexing.time_loc_list
          140±0μs          123±0μs    ~0.88  indexing.IntervalIndexing.time_loc_scalar
```
Speed up of ~10704x for `time_loc_list`

- [x] closes #23576 
- [x] tests added / passed
- [x] passes `git diff upstream/master -u -- "*.py" | flake8 --diff`
- [ ] whatsnew entry _(I don't think this regression has been in a release)_
