WIP: slicing with decreasing monotonic indexes

Fixes #7860 

The first commit adds `Index.is_monotonic_decreasing` and `Index.is_monotonic_increasing` (alias for `is_monotonic`).

`is_monotonic` will have a performance degradation (still O(n) time) in cases where the Index is decreasing monotonic. If necessary, we could work around this, but I think we can probably get away with this because the fall-back options are much slower and in many cases (e.g., for slice indexing) the next thing we'll want to know is if it's decreasing monotonic, anyways.

Next up will be handling indexing monotonic decreasing indexes with reversed slices, e.g., `s.loc[30:10]`.

CC @jreback @hugadams @immerrr (thank you, specialities wiki!)
I think you want to short circuit this and return early if both incr and decr monotonoc are 0 (break out of loop)
so each branch should be something like

if is_monotonoc_incr & cur < prev:
     ....
in the else
if not is_monotonoc_incr & not is_monotonic_decr:
    return False, False, False