API: allow negative steps for label-based indexing
This should fix #8716.

Some of this refactoring may be useful for #8613, so I'd like someone to look through this.

cc'ing @shoyer, @jreback and @jorisvandenbossche .

TODO:
- add tests for label slicing with negative step (ix, loc)
  - [x] int64index
  - [x] float64index
  - [x] objectindex
- [x] fix datetime/period indices
-  add tests for label slicing with negative step (datetime, string, native pandas scalar) x (ix, loc)
  - [x] datetimeindex
  - [x] periodindex
  - [x] timedeltaindex
- [x] clean up old partial string code?
- [x] benchmark

generally seems like a nice refactor to me :+1: 
 This PR will consolidate `Index.slice_locs` with that of Datetime-/Period-/TimedeltaIndex, which means that the non-present lookups on `is_monotonically_decreasing` will start working on those classes.
 Mostly done here, except for
- maybe old partial string slice code can be cleaned up
- per-level slices on MultiIndex don't work and I don't yet see a clear way to support steps for it
- have to check performance
 Again, this looks very nice. Thanks!
 @immerrr maybe you could have a look at https://github.com/pydata/pandas/blob/master/doc/source/internals.rst to see if this is still up to date after your PR (although I am not fully sure this is the best way to document this complex indexing part of the codebase)
 going to have a look tomorrow.
 I've been doing some benchmarking and found the strangest thing: I couldn't get a stable result from `panel_methods.panel_pct_change_major` benchmark, it reported anything from 2000ms to 8000ms. It appears that the task is memory intensive (easily several gbs of ram) and leaves a lot of objects in its wake because timeit disables garbage collection during the benchmarks. The problem is that it doesn't do any cleanup afterwards and this slows down subsequent runs because malloc has harder time finding chunks of memory when requested.

Given usually there's no such thing as "run code before each iteration, but don't benchmark it" in benchmark libraries, I wonder what's the proper way to fix this... Maybe we should just reduce panel sizes in panel benchmarks.
 @immerrr yep that vbench is odd, never really had time to look, feel free to submit a pr to reduce it in size.
 @immerrr looks good. minor case that needs testing. Which might be an open issue in any event (e.g. supporting < second, e.g. microsecond reso in partial_strings for DatetimeIndex).
 I devoted some time to this at the weekend:
- enabled second/microsecond-resolution partial based indexing.
- partial string lookups are going to stay for now, they're used in `get_loc` in seemingly a bit inconsistent way and fixing it may alter the API, so the cleanup will be a separate PR.
 ready & green
 thanks!

keep-em coming!
 Thank you @immerrr !
