BUG: PeriodIndex.order doesnt preserve freq
Closes #10295 (This is based on #10292). Changed `lib.maybe_indices_to_slice` to detect slice with `step` and also check upper bound of index.

However, above change affects to the behavior of `Index.slice_locs`. Internally, the behavoir of `Index.get_slice_bound` seems to assume `lib.maybe_indices_to_slice` returns slice only when its step is "+1". Options are:
1. Change `Index.get_slice_bound` to meet updated `lib.maybe_indices_to_slice` logic.
2. Leave `lib.maybe_indices_to_slice` as it is. Let `DatetimeIndex` to use separate logic, maybe `lib.maybe_indices_to_slice_with_step`

To avoid any unexpected result, I think option 2 is preferable? 

BTW, `__array_finalize__` is never called because it is no longer a subclass of ndarray.

This should be a separate PR, but can I change this to `__finalize__` and let the logic to handle metadata (properties listed in `_attributes`) ?
 The fix should work, but changed the title until we can decide to change `lib.maybe_indices_to_slice` or prepare separate func.
 This is ready for review. I think the point is whether to change `maybe_indices_to_slice` (which is used in base `Index` also), or prepare separate function for datetime-likes.

`__array_finalize__` is being handled in #10638. 
 I have not carefully considered this, but my inclination is that option (1) is preferable (changing `maybe_indices_to_slice`). Which did you choose?
 @shoyer Currently, option 1 (fix `maybe_indices_to_slice`).
 @sinhrks this looks reasonable. you added a huge number of tests (which is gr8!). so will take a bit to look.
 minor comment 
lgtm to me otherwise
merge when ready
 Thanks, fixed the release note and rebased. Will merge when green.
